Re: [autoconf] AmigaOS fork()

[Rüdiger Kuhlmann]

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

> > > I don't think the uses are portable.
> > Wait, why not?
> The latest POSIX draft says this:
> [...]

Okay.

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

Wait, I disagree. If there is no fork(), the platform isn't a POSIX-whatever
platform, so we shouldn't be too strict on what a vfork()ed process is
allowed to do. It doesn't modify variables the parent process uses, but okay
it calles functions, but that seems harmless to me (at least on AmigaOS).

I don't see why the AC_FUNC_WAIT3 test relies on the parent running at the
same time (though I see it with AC_SYS_RESTARTABLE_SYSCALLS - is there
a way to test it just using vfork()?), maybe enlighten me?

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

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

> This part of the patch is unrelated to the topic.

Actually I didn't change anything there, so lay the blame on cvs...

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