On Thu, Oct 05, 2017 at 03:13:07PM -0700, Andres Freund wrote:
> 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.
True, yes. One still has to be careful to fflush() all open FILEs (that
might be used on both sides of fork()) and such though.
> > - 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.
It's trivial to use it where available, and fork() otherwise. Mind you,
all current versions of Solaris/Illumos, *BSD, OS X, and Linux w/glibc
(and even Windows with WSL!) have a true vfork().
> > 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.
glibc has it. Other Linux C libraries might also; I've not checked them
all.
> I do think it'd be good to move more towards threads, but not at all for
> the reasons mentioned here.
You don't think eliminating a large difference between handling of WIN32
vs. POSIX is a good reason?
Nico
--
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers