Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uwm.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: vfork()
Keywords: vfork()
Message-ID: <11383@dog.ee.lbl.gov>
Date: 24 Mar 91 00:38:36 GMT
References: <8372@rsiatl.Dixie.Com> <15533@smoke.brl.mil> <1135@pemcom.pem-stuttgart.de> <7449@idunno.Princeton.EDU> <11366@dog.ee.lbl.gov>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 18
X-Local-Date: Sat, 23 Mar 91 16:38:36 PST

In article <11366@dog.ee.lbl.gov> I wrote:
>[quoting Paul Falstad] ... But another statement above, that
>children of vfork cannot `destroy the parent's stack frame', is not
>correct for (some/many/most?) existing implementations, as even the
>stack is shared.

... which is of course what Paul wrote in the first place.

Just to be absolutely clear on the point:  The child of a vfork must
not return from the function that called vfork, as this could destroy
the (shared) stack frame, causing the parent process to misbehave later.
In some implementations this restriction is relaxed to `if the child
returns, it must not call any other functions'.

These `features' of vfork are subject to change without notice.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov