Re: vfork specs

Geoff Keating (geoffk@ozemail.com.au)
Sat, 16 Jan 1999 17:35:10 +1100


> 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>

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/