Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!jack!crash!kenobi!ford
From: ford@kenobi.UUCP (Mike Ditto)
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: <47@kenobi.UUCP>
Date: 3 Mar 88 09:59:18 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <43@kenobi.UUCP> <997@PT.CS.CMU.EDU>
Organization: Omnicron Data Systems
Lines: 43
In-reply-to: jgm@K.GP.CS.CMU.EDU's message of 29 Feb 88 16:33:10 GMT

Posting-Front-End: GNU Emacs 18.41.10 of Fri Oct  2 1987 on kenobi (usg-unix-v)


In article <997@PT.CS.CMU.EDU> jgm@K.GP.CS.CMU.EDU (John Myers) writes:

> 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.

The main reason that I see is that a Unix domain socket is not really
supposed to show up in the filesystem, and it supposedly doesn't in
more recent BSD releases (4.3?).  I don't think it has ever been clear
whether the "Unix domain" of socket names(addresses) is really
supposed to map into pathnames in the ("open"able) filesystem.  Is it
possible to bind an AF_UNIX socket to "/foo/bar/baz" if there is no
directory "/foo"?  I assume this won't work on 4.2, since it can't
create the "named socket".  But on 4.3 I don't know why it wouldn't
work.  In other words, the "name" that an AF_UNIX socket is bound to
does not need to have any relation to the file system.  You could
probably bind a socket to "/////////".  (I don't know, I haven't been
on a BSD system in quite a while).

> 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.

That would be inconsistent with files, which are not unlinked under those
circumstances.  Either the socket should "really" have a name in the
file system (and be openable, etc.) or it's address should have nothing
to do with the existence or non-existence of a file by the same name.
Both kinds of sockets could be useful.

					-=] Ford [=-

"Well, he didn't know what to do, so	(In Real Life:  Mike Ditto)
he decided to look at the government,	ford%kenobi@crash.CTS.COM
to see what they did, and scale it	...!sdcsvax!crash!kenobi!ford
down and run his life that way." -- Laurie Anderson