autoconf
[Top][All Lists]
Advanced

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

Re: [autoconf] AmigaOS fork()


From: Eric Siegerman
Subject: Re: [autoconf] AmigaOS fork()
Date: Wed, 13 Jun 2001 18:48:03 -0400
User-agent: Mutt/1.2.5i

On Wed, Jun 13, 2001 at 03:28:41PM -0700, Paul Eggert wrote:
> > > > Date: Wed, 13 Jun 2001 00:07:55 +0200
> > > >  * 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.
> > 
> > Something which you'd prefer to have happen in parallel if
> > possible, but if it's not possible, then sequential is ok.
> > "Make" firing off a bunch of compilations, for example.
> 
> The increase in parallelism would be quite small for that application,
> because the extra parallelism would apply only between the fork and
> the exec;

Doh!  Thanks.


> > From: Eric Siegerman <address@hidden>
> > Date: Wed, 13 Jun 2001 17:27:35 -0400
> > 
> > http://www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html)
> > 
> > If this is out to lunch, please tell me,
> 
> That document is isn't quite correct.  First, there are still some
> performance advantages to vfork over fork, even in Linux.

I don't dispute this.

> Also, fork consumes more system
> resources, and sometimes fork will fail where vfork would have
> succeeded.

True, but it fails by returning a known and documented error
status; vfork, if it fails for the reasons being discussed, does
so by scribbling on the parent's data space, with unpredictable
and hard-to-diagnose results.

> It is true that it's hard to implement vfork correctly (see the
> autoconf code for AC_FUNC_VFORK for some of the failure modes).  But
> it can be done, and when it does work correctly it is a win for the
> reasons described above.

Personally, I prefer to fail safe.  In this case, that means
choosing robustness over optimization, especially for autoconf,
which is not an end product over which its programmers have full
control, but a tool that will often be used by people whose
knowledge of these issues is limited, and who may not have a
chance to actually test on a system whose vfork does
address-space sharing.

I'll go away now and stop repeating myself.  I suspect this is
something on which you and I will just have to agree to disagree
... I hope that Akim and Rüdiger will see things my way, of
course :-)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)



reply via email to

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