> From: <[EMAIL PROTECTED]>
> Date: Wed, 13 Jun 2001 00:07:55 +0200
>
> > I don't think the uses are portable.
>
> Wait, why not?
The latest POSIX draft says this:
The vfork() function shall be equivalent to fork(), except that
the behavior is undefined if the process created by vfork()
either modifies any data other than a variable of type pid_t used
to store the return value from vfork(), or returns from the
function in which vfork() was called, or calls any other function
before successfully calling _exit() or one of the exec family of
functions.
None of the uses obey the constraints of that sentence, so they're
not portable to all POSIX 1003.1-200x d6 platforms.
> And if they aren't, would it be okay to change the
> HAVE_WORKING_VFORK to !HAVE_WORKING_FORK?
No. For AC_FUNC_WAIT3 and AC_SYS_RESTARTABLE_SYSCALLS vfork is
definitely the wrong function, as those tests rely on the parent and
child running simultaneously, which is not a portable use of vfork.
And for AC_FUNC_GETPGRP, if fork is not available, the test will
assume that getpgrp has no arguments, which I assume is OK for AmigaOS
(if I'm wrong, please let me know, and we can fix AC_FUNC_GETPGRP
without affecting this vfork issue).
So I don't see why any of those tests should use vfork, even if fork
is not available and vfork is.
> 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)
This code should just use 'fork'
> * vfork(), that can't be a fork().
This code is not portable and should be avoided. But if it is
unavoidable it should be coded with plain 'vfork'.
> * fork(), that should be a fork() if possible, but if not available,
> a vfork() should do the job as well
I don't see why this case would ever happen in real code.
> * vfork(), that should be a vfork() if possible, but if not available,
> fork() does the job as well.
This case is catered to by the usual trick of '#define vfork fork' if
a working vfork is not available.