Re: [HACKERS] Unportable implementation of background worker start

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Unportable implementation of background worker start
Дата
Msg-id 20170421000721.iquvx2nd5s5kch2s@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Unportable implementation of background worker start  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Unportable implementation of background worker start
Список pgsql-hackers
On 2017-04-20 20:05:02 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2017-04-20 19:53:02 -0400, Tom Lane wrote:
> >> So ... what would you say to replacing epoll_create() with
> >> epoll_create1(EPOLL_CLOEXEC) ?  Then a WaitEventSet would not
> >> represent inheritable-across-exec resources on any platform,
> >> making it a lot easier to deal with the EXEC_BACKEND case.
> 
> > I'm generally quite in favor of using CLOEXEC as much as possible in our
> > tree.  I'm a bit concerned with epoll_create1's availability tho - the
> > glibc support for it was introduced in 2.9, whereas epoll_create is in
> > 2.3.2.  On the other hand 2.9 was released 2008-11-13.
> 
> Also, if it's not there we'd fall back to using plain poll(), which is
> not so awful that we need to work hard to avoid it.  I'd just as soon
> keep the number of combinations down.

Just using fcntl(SET, CLOEXEC) wound't increase the number of
combinations?

- Andres



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Unportable implementation of background worker start
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Unportable implementation of background worker start