Re: Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 16, 2016 at 10:34 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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