Re: [autoconf] AmigaOS fork()

[Eric Siegerman]

On Mon, Jun 11, 2001 at 07:42:22PM -0700, Paul Eggert wrote:
> > 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.

The app in question may well be portable.  What's being
discussed, though, is not a system.h hack to that app, but a
patch to autoconf itself.  That argues for being more defensive.

The #define trick is inappropriate here.  You can get away with
it in the strchr/index case, for example, because the two
functions are identical except in name.  More generally, you can
get away with:
        #define a       b
(or the equivalent using true functions) only if a()'s behaviour
is a strict subset of b()'s.  That's not the case with
fork/vfork, in either direction.

You can also get away with it if you never intend to use the part
of a()'s behaviour which b() doesn't share.  So for an app that
knows what it's doing,
        #define fork    vfork
or the reverse, may be fine.  But autoconf doesn't know what the
app is doing (other than that it's spawning a process, of course,
but that's not at all helpful).

Thus, it's inappropriate for autoconf to define either fork() or
vfork() in terms of the other.

The forkvfork() idea would be safest.  The only thing wrong with
it is the name.  How about spawn() instead?  I'll use that in the
following, to give people a chance to react to it :-)

spawn() should be defined as the greatest common subset of fork()
and vfork().  It will therefore be implementable in its entirety
using either one.  That means:
  - the parent may not wake up until the child has called either
    execXX() or exit() -- or it may wake up immediately
  - the child may share the parent's address space -- or it may
    get its own

i.e. spawn() should explicitly not define either of those aspects
of its behaviour.  If you care about one of the above questions,
test the HAVE_WORKING_V?FORK macros and act accordingly if the
host doesn't provide what you need.

And, to repeat my original point, spawn() should prefer fork()
over vfork() when both are available.  The latest draft POSIX
spec only strengthens my argument (thanks, Tim):
> 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.
Again, autoconf isn't in a position to know what the child
process is going to do.

> But
> apparently AmigaOS has a working vfork but not a working fork.

I'd be amazed if anyone could manage an AmigaOS fork!

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

Indeed.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)