Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Fork and Join, Pipe in C
Message-ID: <21731@sun.uucp>
Date: Mon, 22-Jun-87 14:00:59 EDT
Article-I.D.: sun.21731
Posted: Mon Jun 22 14:00:59 1987
Date-Received: Tue, 23-Jun-87 04:58:00 EDT
References: <7737@brl-adm.ARPA> <1186@ius2.cs.cmu.edu> <8174@utzoo.UUCP> <3714@spool.WISC.EDU>
Sender: news@sun.uucp
Lines: 31

> Well, now, I'm not quite sure I agree with this.  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? 

No!  For one thing, the system call *is* doomed, and future implementations
of "vfork" may not *give* you shared memory; in that case, your
program will silently stop working.  For another, you don't
necessarily get *useful* shared memory - after a "vfork", the parent
is blocked until the child either exits or does an "exec", releasing
the shared memory.

> Everyone thinks shm is great, n'est pas?

Yes, shared memory is nice, but "vfork" *isn't* a mechanism for
getting shared memory.

> (So when are we going to see shm in 4.x?  Hmm?)

Don't ask me, I'm not responsible for 4.x.

> Don't misunderstand me - I'm not telling you to use vfork - I'm just
> pointing out that code that uses the semantics of vfork is not
> necessarily "ugly and brain-damaged."

Yes, it is.  There is very little you can do with the (temporarily) shared
memory you get from "vfork", and in most, if not all, cases, you can
do the same thing just as well without it.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com