From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Unportable implementation of background worker start |
Date: | 2017-04-21 00:07:21 |
Message-ID: | 20170421000721.iquvx2nd5s5kch2s@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-04-20 20:05:02 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-21 00:10:41 | Re: Unportable implementation of background worker start |
Previous Message | Tom Lane | 2017-04-21 00:05:02 | Re: Unportable implementation of background worker start |