Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucla-cs!twinsun!eggert
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.sys.sgi
Subject: Re: bug in vfork semantics under IRIX 3.3.1
Message-ID: <1990Nov30.041307.15489@twinsun.com>
Date: 30 Nov 90 04:13:07 GMT
References: <1990Nov29.035827.1302@alias.uucp>
Sender: news@twinsun.com
Organization: Twin Sun, Inc
Lines: 16
Nntp-Posting-Host: ata

chk%alias@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 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.
Even so, surely it is unwise for SGI to supply such a nonstandard vfork(),
because too many people will run into similar problems.