home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: fouts@bozeman.bozeman.ingr (Martin Fouts)
-
- >>>>> On 3 Oct 90 17:19:04 GMT, peter@ficc.ferranti.com (Peter da Silva) said:
- Peter> In article <13132@cs.utexas.edu> fouts@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@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
-
-