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 по дате отправления: