[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/49017: vfork does not suspend all threads
The following reply was made to PR kern/49017; it has been noted by GNATS.
From: Nico Williams <Nico.Williams%twosigma.com@localhost>
Subject: Re: kern/49017: vfork does not suspend all threads
Date: Thu, 6 Apr 2017 15:01:56 +0000
Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> It appears to me as if the discussion on this has largely divided
> along traditional lines - those who (fundamentally) believe that
> vfork() is an evil hack, and should be removed (ideally) but in the
Well, no one seems to have said that, though several seem wedded to
pre-threaded-model text about stopping the parent process and then extending it
to the threaded model in the obvious, but horrible way.
> meantime restricted in all ways possible to limit its use, so that
> hopefully it can go away some day not too far away - and those who
> believe vfork() is a valuable tool, which should be exploited in
> all ways possible, and enhanced where practical to make it even more
I'll take it much further: it is fork() that is EVIL, and vfork() that is GOOD.
Here's my rationale for such an extraordinary statement:
Briefly: fork()'s copying and/or COW are terrible and would never have been
necessary had Dennis Ritchie et. al. thought of vfork()'s semantics. In the
beginning processes were so small that fork()'s copying was not obviously a
horrible feature. Besides, fork() has a ton of safety issues (which I mostly
did not address in that gist, but I could and will) that make vfork() look like
not so bad. Anyone who says that vfork() is impossibly hard to use correctly
without pointing out that fork() is in some ways harder still to use
correctly... just hasn't had the misfortune of having to fix fork-safety
problems in real-life, production code (I have).
Now, vfork() is... clumsy because of the stack sharing silliness, but it
predates threads, so its authors probably did not realize that taking a
callback function and argument to run in a new stack would have been a superior
design -- I forgive them this oversight because vfork() is nonetheless awesome
goodness, and all the more so if it doesn't stop all other threads in the
I didn't always think this way.
I used to think: "haha, look at CreateProcess() on Windows, what a disaster,
how terribly hard it is to use, and all because they had the elegance of
fork()+exec()". But that was wrong. fork() is inelegant. Whereas vfork()+
exec() is quite elegant.
Main Index |
Thread Index |