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. >> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
