Hi, On 2016-05-03 23:09:28 -0400, Robert Haas wrote: > So what's the best API for that? One idea is to change > ModifyWaitEvent to accept events = 0 instead of failing an assertion > inside WaitEventAdjustEpoll. We don't want to wait for EPOLLERR | > EPOLLHUP in that case since we'd have to wait event to return if one > of those things occurred. It would be easy enough to rejigger that > code so that we pass epoll_ev.events as 0 in that case, but I think it > doesn't help: epoll_ctl(2) says epoll_wait(2) always waits for those > events. Instead I think we'd have to use EPOLL_CTL_DEL in that case, > which is a problem: when the user next calls ModifyWaitEvent, we would > need to use EPOLL_CTL_ADD rather than EPOLL_CTL_MOD, but how would we > know that? We'd have to add state for that somewhere.
Right. > Yet another idea is to have a new event WL_SOCKET_ERROR which waits > for only EPOLLERR | EPOLLHUP. So, if you don't care about the socket > being readable or writeable at the moment, but you still vaguely care > about the file descriptor, you can do ModifyWaitEvent(set, pos, > WL_SOCKET_ERROR, NULL). That's actually kind of nice, because now you > can still detect error/eof conditions on sockets that you are not > otherwise waiting for, and report the errors promptly. At the moment, > I'm inclined to think this might be the best option... I generally agree that this is the best option, but there's a noticeable catch: I'm afraid select() doesn't really generally support this kind of operation; all the other providers do. But after trawling the buildfarm logs, that isn't necessarily a problem: It appears that we haven't had a single !windows animal reporting a successfull configure run without HAVE_POLL support this year going by the buildfarm status logs. Running for a longer period now, but it'll take a long while. It appears that OSX with 10.3 was one of the latest to introduce poll() support. Given that poll() has been introduced in SRV3 - which IIRC was below our usual baseline - and windows is not an issue for latch, I think it'd be ok to rely on it. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
