Re: Hang in pldebugger after git commit : 98a64d0

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
Date: 2016-12-17 10:46:59
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

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
>>> *
>> 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.

Attachment Content-Type Size
reset_wait_events_v2.patch application/octet-stream 3.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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