Re: Hang in pldebugger after git commit : 98a64d0

On Sat, Dec 17, 2016 at 9:34 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
>

Yeah, but we are planning to add a generic flag in WaitEvent structure
which can be used for similar purpose. However, as per your
suggestion, I have changed it only for Win32 port. Also, I kept the
change in ModifyWaitEvent API as that seems to be okay considering
'reset' is a generic flag in WaitEvent structure.

>>> 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().
>

I also think so. I have modified your suggested comment in that way.

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