autoconf
[Top][All Lists]
Advanced

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

Re: [autoconf] AmigaOS fork()


From: Paul Eggert
Subject: Re: [autoconf] AmigaOS fork()
Date: Tue, 12 Jun 2001 19:42:47 -0700 (PDT)

> From: <address@hidden>
> 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.



reply via email to

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