On Sat, Dec 17, 2016 at 9:34 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Dec 16, 2016 at 10:34 PM, Amit Kapila <amit.kapil...@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. >
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
reset_wait_events_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
