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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)
Дата
Msg-id 20160504192407.nqz6ra3qpj2pti2o@alap3.anarazel.de
обсуждение исходный текст
Ответ на modifying WaitEventSets (was: Performance degradation in commit ac1d794)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: what to revert
Следующее
От: Tom Lane
Дата:
Сообщение: Re: modifying WaitEventSets (was: Performance degradation in commit ac1d794)