Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 16, 2016 at 10:34 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>  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.

Why?  This is only broken on Windows.  It would be nicer not to touch
any of the un-broken implementations.

>>  BTW, I suggest this rewritten comment:
>>
>>             /*------
>>              * FD_READ events are edge-triggered on Windows per
>>              * https://msdn.microsoft.com/en-us/library/windows/desktop/ms741576(v=vs.85).aspx
>>
>
> Isn't the statement in above doc. "For FD_READ, FD_OOB, and FD_ACCEPT
> network events, network event recording and event object signaling are
> level-triggered." says that FD_READ events are level-triggered which
> seems to be contradictory with above comment?

Argh.  I see your point.  Maybe we'd better rephrase that.  The
document does say that, but the behavior they described is actually a
weird hybrid of level-triggered and edge-triggered.  We should
probably just avoid that terminology altogether and explain that
read-ready won't necessarily be re-signalled unless there is an
intervening recv().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company