Re: [autoconf] AmigaOS fork()

[Paul Eggert]

> From: Eric Siegerman <address@hidden>
> Date: Wed, 13 Jun 2001 17:29:52 -0400
> 
> On Tue, Jun 12, 2001 at 07:42:47PM -0700, Paul Eggert wrote:
> > > From: <address@hidden>
> > > Date: Wed, 13 Jun 2001 00:07:55 +0200
> > >  * fork(), that should be a fork() if possible, but if not available,
> > >    a vfork() should do the job as well
> > 
> > I don't see why this case would ever happen in real code.
> 
> Something which you'd prefer to have happen in parallel if
> possible, but if it's not possible, then sequential is ok.
> "Make" firing off a bunch of compilations, for example.

The increase in parallelism would be quite small for that application,
because the extra parallelism would apply only between the fork and
the exec; there is no extra parallelism after the exec.  In practice I
think this advantage would typically be outweighed by the decrease in
performance due to plain fork's need to copy more page tables.

I suspect that is why GNU make uses vfork.  The source code proper
always says "vfork", though of course this is defined to "fork" on
platforms that lack a working vfork.


> From: Eric Siegerman <address@hidden>
> Date: Wed, 13 Jun 2001 17:27:35 -0400
> 
> http://www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html)
> 
> If this is out to lunch, please tell me,

That document is isn't quite correct.  First, there are still some
performance advantages to vfork over fork, even in Linux.  If your
process has N bytes of virtual memory, then fork requires O(N) time,
whereas vfork requires O(1) time.  Also, fork consumes more system
resources, and sometimes fork will fail where vfork would have
succeeded.  These advantages of vfork increase for large processes.

It is true that it's hard to implement vfork correctly (see the
autoconf code for AC_FUNC_VFORK for some of the failure modes).  But
it can be done, and when it does work correctly it is a win for the
reasons described above.

The bottom line of that page is misleading.  It says "the primary use
of vfork(2) is to support old programs that needed vfork's semantics."
But old programs rarely needed vfork's semantics.  You can take almost
any old program (GNU make, say :-) and substitute "fork" for "vfork",
and it will still work correctly, though it will run more slowly and
use more resources.  That is because these old programs were written
according to the original vfork specification, which said that vfork
might be an alias for fork.