Re: [autoconf] AmigaOS fork()

[Paul Eggert]

> From: Eric Siegerman <address@hidden>
> Date: Mon, 11 Jun 2001 21:19:22 -0400
> 
> Paul Eggert wrote:
> >   the Unix tradition is that code that uses 'vfork' can be safely
> >   changed to use 'fork' if you like.
> 
> If this is a tradition, it's a bad one.  Recall that with vfork,
> the child's memory writes, up till it calls some variant of
> exec(), ARE visible to the parent.

Actually, the original definition of 'vfork' said that one should not
rely on this behavior.  And in the latest POSIX draft (POSIX
1003.1-200x draft 5) the rationale states simply "On some
implementations, vfork() is equivalent to fork()."

Perhaps my point was not clearly stated.  What I was trying to say is
that, if you have portable code that uses "vfork", you should be able
to change it to use "fork" without affecting your application's
correctness.


> (Not that such code was portably written, of course.  At least
> some vfork(2) pages warn against depending on these
> memory-sharing semantics.)

Yes.  A similar warning is also in the latest POSIX draft.


> Paul again:
> >     #if !HAVE_WORKING_VFORK
> >     # define vfork fork
> >     #endif
> > 
> > and then use "vfork" uniformly in the later code.
> 
> For the above reasons, I think it would be a bad idea to use
> vfork() instead of fork() when both are available, and especially
> bad for autoconf to recommend that to people.

My impression is that the code in question uses vfork portably, so it
won't be any more portable if it is changed to use fork.  But
apparently AmigaOS has a working vfork but not a working fork.  If my
understanding is correct, then it's more portable in practice for this
code to use vfork -- with the understanding of course that 'vfork' is
defined to be 'fork' on systems that lack a working vfork.

(This vfork business should all be discussed clearly in the autoconf
documentation, of course -- if anything about vfork can be discussed
clearly.  :-)