Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!usenix!std-unix From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.std.unix Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <475@usenix.ORG> Date: 29 Aug 90 14:01:44 GMT References: <448@usenix.ORG> <467@usenix.ORG> <470@usenix.ORG> Sender: std-unix@usenix.ORG Organization: NCR Microelectronics, Ft. Collins, CO Lines: 35 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) >>>>> On 28 Aug 90 11:58:40 GMT, sp@mysteron.osf.org (Simon Patience) said: >> 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? Simon> The reason for semaphores not being in the file system is twofold. Simon> Some realtime embedded systems do not have a file system but do want Simon> semaphores... Simon> A good reason for *not* having IPC handles in the file system is to Simon> allow network IPC to use the same interfaces. How about adding non-file-system-based "handles" to an mmap-like interface? (e.g. shmmap(host,porttype,portnum,addr,len,prot,flags)?) This could allow the same interface to be used for network and non-network IPC, without the overhead of a trap for every non-network IPC transaction. `Scuse me while I don my flame retardant suit... :-) #include -- Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com 2001 Danfield Ct. Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp Volume-Number: Volume 21, Number 72