Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)

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