Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/v21/201

Internet Message Format | 1990-12-05 | 2KB

From [e-mail]  Thu Oct 11 22:46:46 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA05681; Thu, 11 Oct 90 22:46:46 -0400
Posted-Date: 12 Oct 90 00:31:15 GMT
Received: by cs.utexas.edu (5.64/1.78)
From: [e-mail] (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Peter da Silva)
Organization: Xenix Support, FICC
X-Submissions: [e-mail]
Date: 12 Oct 90 00:31:15 GMT
To: [e-mail]

Submitted-by: [e-mail] (Peter da Silva)

In article <[e-mail]> [e-mail] (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.   `-_-'
[phone].   'U`
[e-mail]



Volume-Number: Volume 21, Number 201