On Sat, Dec 17, 2016 at 3:53 PM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> Hi,
>
>>> I think it should be the responsibility of
>>> WaitEventSetWaitBlock() to reset the event, if needed, before calling
>>> WaitForMultipleObjects().
>>>
>>
>> If we want to change WaitEventSetWaitBlock then ideally we need to
>> change all other wait API's (WAIT_USE_SELECT, WAIT_USE_POLL, etc.) as
>> well. I don't see the need for it, can't we do it in
>> WaitEventSetWait() after processing all the returned events. It can
>> be done by enumerating all wait events and reset the events for which
>> reset flag is true. If we see code prior to 9.6, this event (socket
>> event) has been reset only after processing all returned events, not
>> after every event.
>
> I think we are trying the complicate the things, I would look into the
> fix like this, Let us assume that WaitForMultipleObjects() says an
> event occured on a LATCH then we would save the occured event and
> reset the LATCH immediately inside WaitEventSetWaitBlock() similarly
> if event occurs on SOCKET we should save the occured events and reset
> it. Now, the only concern here is why can't we reset event on SOCKET
> using ResetEvent() API instead of introducing a new variable. I think
> that is just because we are trying to avoid the events for SOCKET from
> being re-created again and again. So, for me i think Amit's fix is
> absolutely fine and is restricted to Windows.
>
It is fine as per current usage of WaitEventSet API's, however,
Robert's point is valid that user is not obliged to call
ModifyWaitEvent before WaitEventSetWait. Imagine a case where some
new user of this API is calling WaitEventSetWait repeatedly without
calling ModifyWaitEvent.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com