Re: [autoconf] AmigaOS fork()

[Paul Eggert]

> From: <address@hidden>
> Date: Wed, 13 Jun 2001 11:52:36 +0200

> I don't see why the AC_FUNC_WAIT3 test relies on the parent running at the
> same time

You're right; I got confused by the 'sleep' in the child, and assumed
that it was checking for a race condition.  But on second thought that
'sleep' is there only to make r.ru_nvcsw nonzero on some hosts.

However, this point is somewhat academic.  Nobody uses wait3 anymore.
(Well, that's not quite true: I just checked all the GNU programs we
have here, and Bash uses wait3 if waitpid does not exist -- but Bash
doesn't care whether wait3 fills in rusage, so it's actually incorrect
for Bash to use AC_FUNC_WAIT3.)

These days portable programs should use waitpid, not wait3.  wait3 is
being removed from the Open Group standards.  It won't appear in the
next revision of POSIX.

So I think AC_FUNC_WAIT3 should be marked as obsolescent, and it's not
worth worrying about whether it works on AmigaOS.

> (though I see it with AC_SYS_RESTARTABLE_SYSCALLS - is there
> a way to test it just using vfork()?), maybe enlighten me?

You should be able to write the test without using either fork or
vfork.  Just use 'alarm'.

On the other hand, I just checked all the GNU programs we use around
here, and only Bash uses AC_SYS_RESTARTABLE_SYSCALLS, and it uses it
incorrectly.  The result of AC_SYS_RESTARTABLE_SYSCALLS has no effect
whatsoever on Bash.

These days portable programs should use SA_RESTART if they want
restartable system calls; they should not rely on
AC_SYS_RESTARTABLE_SYSCALLS, since nowadays the question as to whether
a system call is restartable is a dynamic one, not a
configuration-time one.

So I think AC_SYS_RESTARTABLE_SYSCALLS should be marked as
obsolescent, and it's not worth worrying about whether it works on
AmigaOS.


> > 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
> 
> It happens to be the correct result AFAIK, yes. The ixemul.library providing
> the POSIX-stuff is derived from BSD sources. But - it just _happens_ to be
> the right answer.

That's good enough.  We can worry about other platforms later.  Maybe
we'll continue to luck out.

> > >  * 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.
> 
> Uses of fork() that are only pretty near the requirements of a POSIX
> vfork()? Then it might be better to try vfork() than not to have fork() at
> all.

In my experience, this is not what real programs do.