bug in vfork semantics under IRIX 3.3.1

[Doctor Software]

In article <1990Nov30.041307.15489 at twinsun.com>, eggert at twinsun.com
(Paul Eggert) writes:
> 
> chk%alias at csri.toronto.edu (C. Harald Koch) writes:
> 
> 	Under IRIX, the vfork() call is actually implemented using sproc(),
> 	which is a more primitive way to get multiple processes.  It DOES NOT
> 	give you a separate u-area.  So the setgid() call affects the parent!
> 	...  I strongly suggest not using it at all....
> 

I guess I missed the original posting on this one, but the assumption
here is wrong. sproc(2) creates a new process which shares certain
resources with the parent process. The caller of sproc() is in control
of which are shared. The list includes VM, file descriptors, user and
group IDs, and others. Thus, there >is< a separate u-area for both.
sproc() and vfork() aren't even in the same league - sproc() creates
multiple threads of execution, while vfork() was implemented solely to
speed up the fork/exec sequence.

> I second this suggestion.  Under IRIX 3.3, vfork() also botches file
> descriptors: e.g. if a vfork() child process closes a file, IRIX mistakenly
> closes the corresponding file descriptor in the parent.  I ran into this
> problem porting RCS 5.4 to SGI.
> 
> I couldn't find any SGI documentation for vfork(),
> so I suspect it's both undocumented and unsupported.

Wherever you found a vfork() routine, the underlying sproc() undoubtedly
shares file descriptors with the parent, and thus your problems. As to
support, indeed, vfork() is unsupported by SGI. Please note that vfork()
is supposed to be semantically equivalent to fork(), unless the child
messes up the parent's address space (which the 4.3 manual page warns about).

Vfork() is actually itself a kludge, because it is a response to the
poor performance of fork() on Bezerkley based machines. Because BSD VM
copies the entire address space on fork, fork is expensive. Modern VM
systems (including IRIX) implement copy-on-write as well as text
sharing, so the cost of a fork() call is very small. The proper thing to
do is to fix fork()'s poor performance, not kludge in a system call to
get around it.

Thus, the easiest way to implement vfork() is to add this to the program:

# define vfork	fork

and leave it at that.

> Even so, surely it is unwise for SGI to supply such a nonstandard vfork(),
> because too many people will run into similar problems.

Surely you jest. The entire computer industry would grind to a halt if
every company tried to make sure it only shipped "documented" entry
points to it's libraries.

-- Jim Barton
   Silicon Graphics Computer Systems
   jmb at sgi.com