Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!charon!guido
From: guido@cwi.nl (Guido van Rossum)
Newsgroups: comp.sys.sgi
Subject: Re: bug in vfork semantics under IRIX 3.3.1
Message-ID: <2638@charon.cwi.nl>
Date: 3 Dec 90 10:29:34 GMT
References: <1990Nov29.035827.1302@alias.uucp> <1990Nov30.041307.15489@twinsun.com> <1990Dec2.195600.25725@odin.corp.sgi.com>
Sender: news@cwi.nl
Lines: 21

jmb@patton.wpd.sgi.com (Doctor Software) writes:

>[Reasonable article omitted]
>
>Vfork() is actually itself a kludge, because it is a response to the
>poor performance of fork() on Bezerkley based machines.
                               ^^^^^^^^^
(As an SGI employee you should know better than using such pejoratives.)

From the rest of your story it is clear that SGI is aware that some
programs need vfork().  You also claim that SGI's fork() has adequate
performance to be used instead of vfork().  Then why did someone at SGI
bother to whip up an inadequate vfork() substitute using sproc() while
it could be implemented just as well using fork() trivially, with better
preservation of the semantics?  (Note that the shared memory semantics
of vfork() are explicitly undefined, whereas the non-shared u-area is
essential.)  I'm sure this can be fixed in the next release.

--
Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"A thing of beauty is a joy till sunrise"