Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!usenix!std-unix From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.unix Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <477@usenix.ORG> Date: 30 Aug 90 12:31:01 GMT References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG> Sender: std-unix@usenix.ORG Organization: Teltronics/TCT, Sarasota, FL Lines: 31 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net From: chip@tct.uucp (Chip Salzenberg) According to sp@mysteron.osf.org (Simon Patience): >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. I was under the impression that POSIX was designing a portable Unix interface. Without a filesystem, you don't have Unix, do you? Besides, a given embedded system's library could easily emulate a baby-simple filesystem. >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. The desire for user-space support indicates to me that there should be some provision for non-filesystem (anonymous) IPCs that can be created and used without kernel intervention. This need does not reduce the desirability of putting global IPCs in the filesystem. >A good reason for *not* having IPC handles in the file system is to allow >network IPC to use the same interfaces. Filesystem entities can be used to trigger network activity by the kernel (or its stand-in), even if they do not reside on shared filesystems. -- Chip Salzenberg at Teltronics/TCT , Volume-Number: Volume 21, Number 74