--I2AcQh+/kfs26T/w
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> >Should I replace "vfork" by "fork"?  I don't have enough knowledge to
> >decide.  Any OS guru?

	Depends on the context: I'll explain below.

> The manpage describes a nightmare of undefined and incompatible
> (across systems) behaviour.  It actually describes vfork as "a spectre
> from the past"!  AFAICT vfork is just an optimisation to avoid
> unnecessary copying when the child process immediately does an execve.
> Due to Linux's copy-on-write implementation the overhead is small.  In
> fact, for much of Linux's history vfork was identical to fork.

	And actually, FreeBSD's copy-on-write (base for linux's COW), is 
pretty optimized, so it wouldn't surprise me to hear that vfork is a 
legacy beast (does research)... yup, it is!

> I conclude you should use fork unless you know there is a real
> performance issue on some platform.  This is unlikely to be the case
> on Linux.

	Or BSD.  After looking through Steven's book and reading about 
vfork and fork, I'd have to say this:

* "vfork is intended to create a new process when the purpose of the new 
process is to exec a new program"

* "although it is extremely efficient, vfork has peculiar semantics and 
is generally considered to be an architectual blemish."

	Both quotes taken from Stevens p.193  Hope that helps clarify.  
-sc

-- 
Sean Chittenden

--I2AcQh+/kfs26T/w
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: Sean Chittenden <sean / chittenden.org>

iEYEARECAAYFAjthwnEACgkQn09c7x7d+q1S+ACfeAs2aZlRfou138jV+nx6ZWtM
7xYAoKS9cOyqX4O7CFAu7mVHgdIeQXxl
«Òh
-----END PGP SIGNATURE-----

--I2AcQh+/kfs26T/w--