Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: vfork
Message-ID: <7187@mimsy.UUCP>
Date: Wed, 24-Jun-87 01:22:06 EDT
Article-I.D.: mimsy.7187
Posted: Wed Jun 24 01:22:06 1987
Date-Received: Thu, 25-Jun-87 05:08:19 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3714@spool.WISC.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 14

In article <3714@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes:
>... I'll admit that taking advantage of the semantics of a doomed
>system call is ugly.  But suppose I were to phrase it like this:
>I wasn't taking advantage of vfork, I just had a need for shared
>memory.  Then it's probably ok, right? 

Vfork() is no good for shared memory, since the parent is not run
until the child throws away its own memory via exec() or _exit().
That is, the memory is not *shared*, it is *given away* to the
child until the child no longer needs it.  Without any memory, the
parent process cannot do anything.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris