Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!tut.cis.ohio-state.edu!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: <11366@dog.ee.lbl.gov> Date: 23 Mar 91 00:49:35 GMT References: <8372@rsiatl.Dixie.Com> <15533@smoke.brl.mil> <1135@pemcom.pem-stuttgart.de> <7449@idunno.Princeton.EDU> Reply-To: torek@elf.ee.lbl.gov (Chris Torek) Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 40 X-Local-Date: Fri, 22 Mar 91 16:49:35 PST In article <7449@idunno.Princeton.EDU> pfalstad@phoenix.Princeton.EDU (Paul Falstad) writes: >The [vfork] parent cannot exit because it's not running; it waits for the >child to exit or exec first. The child can do whatever it wants to the >parent's data segment before it exit()s or exec()s (except destroy the >parent's stack frame) without causing garbage. You could even use this call >for a horribly unportable shared memory hack if you wanted. Vfork is not really useful for shared memory because (as noted above) the parent process does not run. 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. This causes no little concern in the vfork library stub routine, which must return *before* it makes the system call! On a Vax, the trick is (after rewriting Ovfork.s completely, as the old one was too gross): ENTRY(vfork) movl 16(fp),r2 # save return address before we smash it movab here,16(fp) ret here: chmk $SYS_vfork bcs err # if failed, set errno and return -1 mnegl r1,r1 # r1 = 0xffffffff if child, 0 if parent bicl2 r1,r0 # r0 &= ~r1, i.e., 0 if child, else unchanged jmp (r2) err: movl r0,_errno mnegl $1,r0 jmp (r2) The mnegl/bicl2 trick is my fault (it shaves one instruction off the more straightforward `tstl r1; beql parent; clrl r0; parent:' sequence, and it avoids branches). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov