|From:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Hang in pldebugger after git commit : 98a64d0|
|Views:||Raw Message | Whole Thread | Download mbox|
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
>> 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
> 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.
|Next Message||Amit Kapila||2016-12-17 10:51:21||Re: Hang in pldebugger after git commit : 98a64d0|
|Previous Message||Ashutosh Sharma||2016-12-17 10:23:34||Re: Hang in pldebugger after git commit : 98a64d0|