On March 18, 2016 11:52:08 PM PDT, Amit Kapila <amit.kapil...@gmail.com> wrote: >On Sat, Mar 19, 2016 at 12:14 PM, Andres Freund <and...@anarazel.de> >wrote: >> >> >> >> On March 18, 2016 11:32:53 PM PDT, Amit Kapila ><amit.kapil...@gmail.com> >wrote: >> >On Sat, Mar 19, 2016 at 12:00 AM, Andres Freund <and...@anarazel.de> >> >wrote: >> >> >> >> On 2016-03-18 20:14:07 +0530, Amit Kapila wrote: >> >> >> >> > I have done some >> >> > tests on Windows with 0003 patch which includes running the >> >regressions >> >> > (vcregress check) and it passes. Will look into it tomorrow >once >> >again >> >and >> >> > share if I find anything wrong with it, but feel to proceed if >you >> >want. >> >> >> >> Thanks for the testing thus far! Let's see what the buildfarm has >to >> >> say. >> >> >> > >> >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? It's be absurdly broken if it handled edge triggered enemy's like FD_CLOSE in a way you can't discover. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
