Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!usenix!std-unix
From: sp@mysteron.osf.org (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <470@usenix.ORG>
Date: 28 Aug 90 11:58:40 GMT
References: <448@usenix.ORG> <467@usenix.ORG>
Sender: std-unix@usenix.ORG
Reply-To: sp@mysteron.osf.org (Simon Patience)
Organization: Open Software Foundation
Lines: 40
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

From:  sp@mysteron.osf.org (Simon Patience)

In article <467@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
>From:  chip@tct.uucp (Chip Salzenberg)
>
>>     Finally, the group accepted abandoning the use of
>>     file descriptors for semaphore handles, but some participants
>>     wanted to keep semaphore names pathnames.
>
>Aargh!  Almost everyone realizes that System V IPC is a botch, largely
>because it doesn't live in the filesystem.  So what does IEEE do?
>They take IPC out of the filesystem!
>
>What sane reason could there be to introduce Yet Another Namespace?

The reason for semaphores not being in the file system is twofold. Some
realtime embedded systems do not have a file system but do want semaphores
So this allows them to have them without having to bring in the baggage a
file system would entail. Secondly, as far as threads, which are supposed to
be light weight, are concerned it allows semaphores to be implmented in user
space rather than forcing them into the kernel for the file system.

A good reason for *not* having IPC handles in the file system is to allow
network IPC to use the same interfaces. If you have IPC handles in the
file system then two machines who have applications trying to communicate
would also have to have at least part of their file system name space to
be shared. This is non trivial to arrange for two machines so can you
imaging the problem of doing this for 100 (or 1000?) machines.

I am just the messenger for these views and do not necessarily hold them
myself. They were the reasons that came up during the discussion.

Simon.

  Simon Patience				Phone: (617) 621-8736
  Open Software Foundation			FAX:   (617) 225-2782
  11 Cambridge Center				Email: sp@osf.org
  Cambridge MA 02142				       uunet!osf.org!sp

Volume-Number: Volume 21, Number 68