Re: Performance degradation in commit ac1d794

On Sun, Mar 20, 2016 at 7:13 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2016-03-19 15:43:27 +0530, Amit Kapila wrote:
> > On Sat, Mar 19, 2016 at 12:40 PM, Andres Freund <andres(at)anarazel(dot)de>
wrote:
> > >
> > > On March 18, 2016 11:52:08 PM PDT, Amit Kapila <
amit(dot)kapila16(at)gmail(dot)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 this is just incredibly bad documentation. See
> https://blogs.msdn.microsoft.com/oldnewthing/20150409-00/?p=44273
> (Raymond Chen can be considered an authority here imo).
>

The article pointed by you justifies that the way ResetEvent is done by
patch is correct. I am not sure, but you can weigh, if there is a need of
comment so that if we want enhance this part of code (or want to write
something similar) in future, we don't need to rediscover this fact.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com