Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!fletcher
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <13506@cs.utexas.edu>
Date: 12 Oct 90 00:31:15 GMT
References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG> <553@usenix.ORG> <13132@cs.utexas.edu> <13156@cs.utexas.edu> <13442@cs.utexas.edu>
Sender: fletcher@cs.utexas.edu
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 25
Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: peter@ficc.ferranti.com (Peter da Silva)

In article <13442@cs.utexas.edu> fouts@bozeman.bozeman.ingr (Martin Fouts) writes:
> Short persistance IPC mechanisms found in multithreaded shared memory
> implementations consist of a small region of memory and a lock guarding
> that region.  Producer/consumer parallelism using this mechanism does
> not need to be visible.  Effectively, this is the shared memory
> equivalent of an unnamed pipe.

Effectively, this *is* shared memory. And shared memory has proven itself
to be a viable candidate for insertion into the name space.

I didn't say that every application of an IPC mevchanism should have its
own entry in the name space. Creating a file for each element in a shared
memory region makes about as much sense as creating a file for each
message in a pipe. But the region itself should be visible from the
outside.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com



Volume-Number: Volume 21, Number 201