From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Nico Williams <nico(at)cryptonector(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: fork()-safety, thread-safety |
Date: | 2017-10-05 22:13:07 |
Message-ID: | 20171005221307.uvtepb37pcmhypnv@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2017-10-05 17:02:22 -0500, Nico Williams wrote:
> A quick look at the functions called on the child side of fork()
> makes me think that it's unlikely that the children here use
> async-signal-safe functions only.
That's not a requirement unless you're using fork *and* threads. At
least by my last reading of posix and common practice.
> - fork() is used in a number of places where execl() or execv() are
> called immediately after (and exit() if the exec fails).
>
> It would be better to use vfork() where available and _exit() instead
> of exit().
vfork is less portable, and doesn't really win us anything on common
platforms. On most it's pretty much the same implementation.
> vfork() is widely demonized, but it's actually quite superior
> (performance-wise) to fork() when all you want to do is exec-or-exit
> since no page copying (COW or otherwise) needs be done when using
> vfork().
Not on linux, at least not as of a year or two back.
I do think it'd be good to move more towards threads, but not at all for
the reasons mentioned here.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2017-10-05 22:14:08 | Re: search path security issue? |
Previous Message | Joshua D. Drake | 2017-10-05 22:05:07 | Re: search path security issue? |