On Sat, Dec 17, 2016 at 3:53 PM, Ashutosh Sharma <ashu.coe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
