| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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-20 23:53:02 |
| Message-ID: | 4643.1492732382@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-04-20 19:23:28 -0400, Tom Lane wrote:
>>> or are the HANDLEs in a Windows WaitEventSet not inheritable
>>> resources?
>> So that kind of sounds like it should be doable.
> Ah, good. I'll add a comment about that and press on.
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.
AFAIK, both APIs are Linux-only, and epoll_create1() is not much
newer than epoll_create(), so it seems like we'd not be giving up
much portability if we insist on epoll_create1.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-20 23:59:19 | Re: Unportable implementation of background worker start |
| Previous Message | Andres Freund | 2017-04-20 23:44:20 | Re: Unportable implementation of background worker start |