On Sat, Mar 19, 2016 at 12:40 PM, Andres Freund <andres@anarazel.de> wrote: > > On March 18, 2016 11:52:08 PM PDT, Amit Kapila <amit.kapila16@gmail.com> wrote: > >> >Won't the new code needs to ensure that ResetEvent(latchevent) > >should > >> >get > >> >called in case WaitForMultipleObjects() comes out when both > >> >pgwin32_signal_event and latchevent are signalled at the same time? > >> > >> WaitForMultiple only reports the readiness of on event at a time, no? > >> > > > >I don't think so, please read link [1] with a focus on below paragraph > >which states how it reports the readiness or signaled state when > >multiple > >objects become signaled. > > > >"When *bWaitAll* is *FALSE*, this function checks the handles in the > >array > >in order starting with index 0, until one of the objects is signaled. > >If > >multiple objects become signaled, the function returns the index of the > >first handle in the array whose object was signaled." > > I think that's OK. We'll just get the next event the next time we call waitfor*. It's also not different to the way the routine is currently handling normal socket and postmaster events, no?
>
I think the primary difference with socket and postmaster event as compare to latch event is that it won't allow to start waiting with the waitevent in signalled state. For socket event, it will close the event in the end and create again before entring the wait loop in WaitLatchOrSocket. I could not see any major problem apart from may be spurious wake ups in few cases (as we haven't reset the event to non signalled state for latch event before entering wait, so it can just return immediately) even if we don't Reset the latch event.