autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [autoconf] AmigaOS fork()


From: Rüdiger Kuhlmann
Subject: Re: [autoconf] AmigaOS fork()
Date: Wed, 13 Jun 2001 00:07:55 +0200
User-agent: Mutt/1.3.18i

>--[Paul Eggert]--<address@hidden>

> ... Kuhlmann's patch ...

*giggle* feel free to use my first name.

> I don't think the uses are portable.

Wait, why not? And if they aren't, would it be okay to change the
HAVE_WORKING_VFORK to !HAVE_WORKING_FORK?

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

If you really need a name, why not "anyfork"? Or "weakfork"?

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

The problem is that neither the existance of a working fork() nor vfork() is
guaranteed. This leads to four(!) different cases:

 * fork(), that must unavoidable be a fork(), not a vfork(), even if it
   means it always fails (like double-forking)
 * fork(), that should be a fork() if possible, but if not available,
   a vfork() should do the job as well
 * vfork(), that should be a vfork() if possible, but if not available,
   fork() does the job as well.
 * vfork(), that can't be a fork().

The second case might be the case with our test programs that were using
fork(), the third case is the vfork()+exec() combo, and the fourth is
probably only in old unportable code relying on being able to mess with the
parent's memory.

Now, if people try not to use vfork() for portability reasons or because
POSIX wants to get rid of vfork(), what should we suggest people to use?
Maybe ask them to use vfork, but define it to fork depending on their taste
either if HAVE_WORKING_FORK or !HAVE_WORKING_VFORK? Or both at the same
time? Then we need a third name.

Anyway, it's late, so I hope it made sense...

Yours, Rüdiger.

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Ghandi



reply via email to

[Prev in Thread] Current Thread [Next in Thread]