Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!agate!ig!uwmcsd1!bbn!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!jgm
From: jgm@K.GP.CS.CMU.EDU (John Myers)
Newsgroups: comp.unix.wizards
Subject: Re: Here's the flame everyone's asking for (was Re: Shared Memory in BSD4.3 is lacking?)
Message-ID: <997@PT.CS.CMU.EDU>
Date: 29 Feb 88 16:33:10 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <43@kenobi.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: System/Technology Development Corp.
Lines: 18

In article <43@kenobi.UUCP> ford@kenobi.UUCP (Mike Ditto) writes:
>In article <2009@ho95e.ATT.COM> wcs@ho95e.ATT.COM (Bill.Stewart) writes:
[ Justified Missed'em V flaming ]
>On Berkeley Unix, the primary IPC mechanism (the socket) is very
>nicely implemented in a way consistent with the previously existing
>I/O facilities.  In particular, it is accessed in the same way as
>files and other I/O: with a "file" descriptor.

Then why the heck can't you open(2) a BSD unix domain socket?  The
semantics seem pretty obvious. (Create a new socket and connect to
the socket named in the open call.)  Sounds like <10 lines of code to
me.

Something that would be harder, but would still be incredibly useful
would be to automaticly unlink a socket when the (last) process owning
that socket exits.

-- 
John G. Myers				John.Myers@k.gp.cs.cmu.edu