Standards Update, IEEE 1003.4: Real-time Extensions

[Martin Fouts]

Submitted-by: fouts at bozeman.bozeman.ingr (Martin Fouts)

>>>>> On 3 Oct 90 17:19:04 GMT, peter at ficc.ferranti.com (Peter da Silva) said:
Peter> In article <13132 at cs.utexas.edu> fouts at bozeman.bozeman.ingr (Martin Fouts) writes:
> One reason to not treat every IPC facility as part of the file system:
> Shared memory IPC mechanisms which don't need to be visible to
> processes not participating in the IPC.

Peter> Provide an example, considering the advantages of having shell level
Peter> visibility of objects has for (a) debugging, (b) system administration,
Peter> (c) integration, (d)...

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.

a) debugging is handled by the process debugger, not by the shell and
   has the same visibility as any other memory resident data.

b) There is no system administration, since the objects have exactly
   process duration with the same termination semantics as a pipe, in
   that termination of any of the processes is usually catastrophic

c) I'm not sure what integration support would benefit from making
   a short duration object visible.

d) ....

--
Martin Fouts

 UUCP:  ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts
 ARPA:  apd!fouts at ingr.com
PHONE:  (415) 852-2310            FAX:  (415) 856-9224
 MAIL:  2400 Geng Road, Palo Alto, CA, 94303

Moving to Montana;  Goin' to be a Dental Floss Tycoon.
  -  Frank Zappa


Volume-Number: Volume 21, Number 196