Re: vfork specs

[Geoff Keating <geoffk@ozemail.com.au>]

> Date: Fri, 15 Jan 1999 15:22:29 -0500
> From: Roland McGrath <roland@frob.com>
> Cc: GNU libc testers <libc-alpha@cygnus.com>,
>         VGER gcc list <linux-gcc@vger.rutgers.edu>,
>         VGER kernel list <linux-kernel@vger.rutgers.edu>
> X-Windows: some voids are better left unfilled.
> 
> All true vfork implementations in all systems have had these restrictions,
> whether cleared stated by their documentation or not.  If you think about
> it, the issue is inherent in the memory sharing behavior vfork is specified
> to have.

The Solaris manual page says:

NOTES
     The use of vfork() for any purpose except as a prelude to an
     immediate  call  to  a  function from the exec family, or to
     _exit(), is not advised.

     vfork() is unsafe in multi-thread applications.

     This function will be eliminated in a future  release.   The
     memory  sharing semantics of vfork() can be obtained through
     other mechanisms.

     To avoid a possible deadlock situation, processes  that  are
     children  in  the middle of a vfork() are never sent SIGTTOU
     or SIGTTIN signals; rather, output or ioctls are allowed and
     input attempts result in an EOF indication.

     On some systems, the implementation of  vfork()  causes  the
     parent  to inherit register values from the child.  This can
     create  problems  for  certain   optimizing   compilers   if
     <unistd.h> is not included in the source calling vfork().

The Solaris vfork() does not permit the child's computation to be
interleaved with the parent's; after vfork(), the parent cannot run
until the child exits or calls exec.  Except in multi-threaded
applications, when only the calling thread of control is suspended,
see the second paragraph from the manual page.
-- 
Geoffrey Keating <geoffk@ozemail.com.au>