Re: [autoconf] AmigaOS fork()

[Paul Eggert]

> From: Eric Siegerman <address@hidden>
> Date: Tue, 12 Jun 2001 15:02:58 -0400
> 
> 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.

But it is true for 'vfork' if you use vfork portably.  This is because
portable uses of 'vfork' work even if 'vfork' is an alias for 'fork'.
So it is reasonable for the autoconf documentation to recommend
'#define vfork fork' for use in portable applications on hosts that
lack vfork.

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

I wasn't talking about arbitrary applications: I was talking only
about the little test functions that autoconf uses.  If these test
functions use 'fork' in such a way that 'vfork' will suffice, then
it's OK for them to use 'vfork' if available.

However, you do have a point that we should check those applications
carefully.  I assumed that these functions could use vfork, since
Kuhlmann's patch did it that way for AmigaOS.  However, now that I
look at his patch more carefully, I don't think the uses are portable.
So I'll suggest that he drop that part of the patch.  This should
address some of your objections, though perhaps not all of them.

> The forkvfork() idea would be safest.  The only thing wrong with
> it is the name.  How about spawn() instead?

We shouldn't use that name, because POSIX 1003.1-200x draft 6 has its
own idea of what spawning is, and we shouldn't usurp that terminology.

> spawn() should be defined as the greatest common subset of fork()
> and vfork().

But for portable code, there is no difference between 'vfork' and your
'spawn'.  I don't see why we need a new name for it.  There are
already too many types of forking out there in the real world, and I'd
rather not invent another name just for the autoconf manual.

> And, to repeat my original point, spawn() should prefer fork()
> over vfork() when both are available.

In many applications, vfork is preferable to fork, not only because it
runs faster, but because it is less likely to fail with errno==ENOMEM.