Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!pasteur!ucbvax!hplabs!sdcrdcf!ism780c!mikep
From: mi...@ism780c.UUCP (Michael A. Petonic)
Newsgroups: comp.unix.wizards
Subject: Shared Memory in BSD4.3 is lacking?
Message-ID: <9100@ism780c.UUCP>
Date: 19 Feb 88 10:45:44 GMT
Reply-To: mi...@ism780c.UUCP (Michael A. Petonic)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 32


Now, don't get me wrong.  I like Berzerkeley and all, but JEEZ!  No
shared memory?  After implimenting a program to use shared memory in
BSD (from the specs in the "Berkeley Software Architecture Manual (4.3
edition)") and trying to compile it, I notied I'm missing some
functions.  So, I look really really really close at the page and
there is a footnote that in effect say "We don't have any of these
functions implemented, yet."

What gives?  After trying various methods to communicate information
accross the parent-child barrier, I am convinced that shared memory is
the only way to go.

Can someone more familiar with BSD give me a hand?  Is there
a crufty trick I can use with sockets to have *fast* interprocess
communication?  

What I'd really like to do is to share a file pointer (that's
right, a file pointer, not a file descriptor) accross processes
along with several variables.  Any decent ways out there?

-MikeP
--------
Michael A. Petonic                      (213) 453-8649 x3247
INTERACTIVE Systems Corporation         "My opinions in no way influences
2401 Colorado Blvd.                     the price of tea in China."
Santa Monica, CA. 90404
{sdcrdcf|attunix|microsoft|sfmin}!ism780c!mikep

additional disclaimer:  I'm a System V man out of necessity, so
no "What!?!?!  You don't know every detail of sockets and
datagrams???" type flames, please.

Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!trantor.umd.edu!chris
From: ch...@trantor.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2329@umd5.umd.edu>
Date: 20 Feb 88 14:36:50 GMT
References: <9100@ism780c.UUCP>
Sender: r...@umd5.umd.edu
Reply-To: ch...@trantor.umd.edu (Chris Torek)
Organization: University of Maryland, College Park
Lines: 29

(Answer: Yes.)

In article <9...@ism780c.UUCP> mi...@ism780c.UUCP (Michael A. Petonic) writes:
>Now, don't get me wrong.  I like Berzerkeley and all, but JEEZ!  No
>shared memory?
[stuff about mmap deleted]
>What gives?

Nobody was quite sure how mmap `ought' to work, and it never got
implemented.  It is likely to be in `4.4', which is not what the
next release is going to be.  (Thoroughly confused yet?)

Anyway, BSD does not have System V style shared memory (which might
more accurately be called `USG 3.0 style shared memory') because
System V shared memory is wrong.  (Now there is a good flammable
statement for you :-) )

>What I'd really like to do is to share a file pointer (that's
>right, a file pointer, not a file descriptor) accross processes
>along with several variables.

What kind of `file pointer'?  Kernel file pointers (indexed by user
file descriptors) are in fact shared.  stdio `FILE *'s are not.
Basically, under 4.3BSD, you are stuck with a system call per remote
variable access (read: slow).  You could write a special device
driver that cheats, and acts like System V shared memory....
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
Domain: ch...@mimsy.umd.edu		Path: not easily reachable

Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!ucsfcgl!cca.ucsf.edu!rk9005
From: rk9...@cca.ucsf.edu (Roland McGrath)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <1155@ucsfcca.ucsf.edu>
Date: 20 Feb 88 23:29:14 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu>
Reply-To: rol...@rtsg.lbl.gov (Roland McGrath)
Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome)
Lines: 13

["Shared Memory in BSD4.3 is lacking?"] - ch...@trantor.umd.edu (Chris Torek):
} implemented.  It is likely to be in `4.4', which is not what the
} next release is going to be.  (Thoroughly confused yet?)

Okay, I'll give.  What *will* the next release be??????
Yes, thank you, I am now thoroughly confused; I guess that's
what you wizard/guru types do for fun when you're not describing
the universe to us all.
-- 
Dick Karpinski  Manager of Unix Services, UCSF Computer Center
UUCP:  ...!ucbvax!ucsfcgl!cca.ucsf!dick        (415) 476-4529 (11-7)
BITNET:  dick@ucsfcca or dick@ucsfvm           Compuserve: 70215,1277  
USPS:  U-76 UCSF, San Francisco, CA 94143-0704   Telemail: RKarpinski   

Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!purdue!umd5!trantor.umd.edu!chris
From: ch...@trantor.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2353@umd5.umd.edu>
Date: 24 Feb 88 21:31:37 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <1155@ucsfcca.ucsf.edu>
Sender: r...@umd5.umd.edu
Reply-To: ch...@trantor.umd.edu (Chris Torek)
Organization: University of Maryland, College Park
Lines: 23

>ch...@trantor.umd.edu (me):
>} It is likely to be in `4.4', which is not what the
>} next release is going to be.  (Thoroughly confused yet?)

In article <1...@ucsfcca.ucsf.edu> rol...@rtsg.lbl.gov (Roland McGrath) writes:
>Okay, I'll give.  What *will* the next release be??????

I wish I knew.  Mike Karels had been using the name `4.3a' temporarily,
but found that IBM has already used that name for a PC/RT release.
In the meantime, I have been calling it `4.3+', `4.3++', and (the
latest) `4.3T': T for Tahoe.

Anyway, there *is* an update to 4.3BSD in the wings, but it probably will
not be called 4.4.  Apparently tacking a suffix onto an existing name
makes it easier to convince the lawyers to use the same contract, or
something.

>Dick Karpinski  Manager of Unix Services, UCSF Computer Center

(So why does not this match the author name listed above?)
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(hiding out on trantor.umd.edu until mimsy is reassembled in its new home)
Domain: ch...@mimsy.umd.edu		Path: not easily reachable

Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!oddjob!gargoyle!ihnp4!att-cb!clyde!ho95e!wcs
From: w...@ho95e.ATT.COM (Bill.Stewart)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2009@ho95e.ATT.COM>
Date: 26 Feb 88 00:04:00 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu>
Reply-To: w...@ho95e.UUCP (46323-Bill.Stewart,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 18

In article <2...@umd5.umd.edu> ch...@trantor.umd.edu (Chris Torek) writes:
:Anyway, BSD does not have System V style shared memory (which might
:more accurately be called `USG 3.0 style shared memory') because
:System V shared memory is wrong.  (Now there is a good flammable
:statement for you :-) )

Ok, I'll flame!  What's wrong with System V shared memory?
I agree that the user interface is annoying, having chosen
clunky-but-general over cleaner-but-less-general, but that's not a
major loss.  (At least it's less annoying than semaphores.)

So what's missing, or otherwise brain-damaged?  Much of the problem
with the interface is that your program has to find and hook up to
shared memory somehow, and the shared memory has to be able to
stick around when unused.  The magic cookie approach seems
reasonable.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!purdue!umd5!trantor.umd.edu!chris
From: ch...@trantor.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2368@umd5.umd.edu>
Date: 28 Feb 88 10:23:18 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM>
Sender: r...@umd5.umd.edu
Reply-To: ch...@trantor.umd.edu (Chris Torek)
Organization: University of Maryland, College Park
Lines: 45

>In article <2...@umd5.umd.edu> I wrote:
>:Anyway, BSD does not have System V style shared memory ... because
>:System V shared memory is wrong.  (Now there is a good flammable
>:statement for you :-) )

In article <2...@ho95e.ATT.COM> w...@ho95e.UUCP
(46323-Bill.Stewart,2G218,x0705,) writes:

[For what *are* all those numbers in your name, anyway? :-) ]

>Ok, I'll flame!  What's wrong with System V shared memory?

You name it yourself.  First:

>I agree that the user interface is annoying,

(It feels like something IBM might have invented.)

>having chosen clunky-but-general over cleaner-but-less-general,

There are cleaner approaches that are still general.  While it is
true that most hardware restricts sharing to page-sized or larger
segments, finding sharable locations in SysV is not at all easy.
Moreover:

>Much of the problem with the interface is that your program has
>to find and hook up to shared memory somehow, and the shared
>memory has to be able to stick around when unused.

Now, name something that any Unix program can find, and that sticks
around when unused (at least until you run `rm' ...  oops, I think
I just gave it away :-) ).  *Why* does SysV use an entirely separate
name space for shared memory?  (Answer: because it was easy to
write that way.)

Additionally, the total number of shared pages allowed is, I believe,
compiled into the kernel.  (There are a number of similar grotesqueries
in the 4BSD kernel, again because it was easy to implement that
way.)  Finally, there is, it seems, no way to have sbrk and shm*
co-operate.  The future BSD shared memory will cure all of these
defects, or at least we think so....
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(still on trantor.umd.edu because mimsy is not yet re-news-networked)
Domain: ch...@mimsy.umd.edu		Path: ...!uunet!mimsy!chris

Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!hubcap!ncrcae!ncr-sd!crash!kenobi!ford
From: f...@kenobi.UUCP (Mike Ditto)
Newsgroups: comp.unix.wizards
Subject: Here's the flame everyone's asking for (was Re: Shared Memory in BSD4.3 is lacking?)
Message-ID: <43@kenobi.UUCP>
Date: 29 Feb 88 04:19:13 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM>
Organization: Omnicron Data Systems
Lines: 81
Summary: SysV IPC is OK, but could have been more Unix-like (like BSD sockets)
In-reply-to: wcs@ho95e.ATT.COM's message of 26 Feb 88 00:04:00 GMT

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


In article <2...@ho95e.ATT.COM> w...@ho95e.ATT.COM (Bill.Stewart) writes:

> Ok, I'll flame!  What's wrong with System V shared memory?

Hmm... asking for trouble...  :-)

Actually, I like System V shared memory.  It has many useful features
and I have used it very successfully in several projects.  However, I
do have a few observations about System V IPC in general.

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.  In fact, the socket
completely replaces the less general pipe mechanism.  A socket
descriptor can be accessed with the "read" and "write" system calls
(although socket-specific calls are also available).  On any
descriptor (file, device, or socket) the fstat() system call can be
used to determine what type it is, but few programs need to know.

With System V IPC (Shared Memory, Semaphores, and Message Queues)
special system calls are needed not only to create the "ID"s, but also
to access them.  These special access methods are necessary, of
course, but why not allow the normal access methods to work as well?
Why can't you read(2) and write(2) to message queues?  Why can't you
have a named semaphore or shared memory segment.  Why can't you use
fcntl(fd, F_SETFD, arg) to specify whether shared memory should be
inherited by exec(2)'d processes.

If System V IPC had been done "right":

	"/dev/kmem" could be a named shared memory segment, which,
	like all shared memory segments, could be accessed via
	lseek/read/write or mapped into a process's address space.

	IPC objects could have names in the filesystem, and be
	manipulated with normal commands.  You could use "rm" to
	delete a message queue, or "ls" to see which ones exist,
	just like you can see which devices are in /dev.

	You could use these names as arguments to programs, or put them
	in the environment.  For example, consider a multi-user
	conferencing system (like Compuserve "CB") that looked at the
	"CONFCHANNEL" environment variable for a name of a default
	shared memory segment to communicate through.

	The shell could use normal I/O redirection to connect programs
	via IPC.

	Shell scripts could easily use IPC.

	And so on...

Not all the IPC functions are directly mappable to read, write, etc.,
(what should reading from a semaphore do?) but it still wouldn't hurt
to give them file descriptors for the reasons above.  It's not any
different than having a line printer device which does nothing useful
in reply to a read() system call.

All the existing capability could have been provided, while giving a
more consistent view of the IPC mechanisms.  BSD Unix allows normal
read/write access to sockets, but provides additional system calls
that allow more detailed and socket specific control over I/O.  All
the old articles about Unix from Bell Labs in the seventies boasted
about the revolutionary idea of I/O and pipes that look the same as
file access.  And yet AT&T didn't live up to that concept in their IPC
enhancements.

From a practical point of view, it doesn't make much difference.  System
V IPC provides sufficiently powerful facilities to be very useful and
not too difficult to use, (once you are familiar with it, which won't
happen from reading the documentation).  I just think it could have been
made more consistent with the Unix philosophy without any loss of
functionality, and it would have opened up some interesting
possibilities like the examples above.

					-=] Ford [=-

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

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: j...@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: netn...@PT.CS.CMU.EDU
Organization: System/Technology Development Corp.
Lines: 18

In article <4...@kenobi.UUCP> f...@kenobi.UUCP (Mike Ditto) writes:
>In article <2...@ho95e.ATT.COM> w...@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.My...@k.gp.cs.cmu.edu

Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!jack!crash!kenobi!ford
From: f...@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 <9...@PT.CS.CMU.EDU> j...@K.GP.CS.CMU.EDU (John Myers) writes:

> In article <4...@kenobi.UUCP> f...@kenobi.UUCP (Mike Ditto) writes:
> >In article <2...@ho95e.ATT.COM> w...@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%ken...@crash.CTS.COM
to see what they did, and scale it	...!sdcsvax!crash!kenobi!ford
down and run his life that way." -- Laurie Anderson

Path: utzoo!mnetor!uunet!nbires!hao!gatech!purdue!riedl
From: ri...@cs.purdue.EDU (John T Riedl)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <3371@medusa.cs.purdue.edu>
Date: 1 Mar 88 22:19:52 GMT
Sender: n...@cs.purdue.EDU
Organization: Department of Computer Science, Purdue University
Lines: 9

Another feature of the choice to make semaphores/FIFOs/shared memory
segments different from file descriptors is that select(3) presumably
won't work with them.  How does one check the condition "is data ready
on my queue or on my UDP port?"

Thanks,
-- 
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl  -or-  ri...@mordred.cs.purdue.edu

Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!jack!crash!kenobi!ford
From: f...@kenobi.UUCP (Mike Ditto)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <52@kenobi.UUCP>
Date: 4 Mar 88 04:40:15 GMT
References: <3371@medusa.cs.purdue.edu>
Organization: Omnicron Data Systems
Lines: 26
Summary: Even select(2) would make sence on IPC descriptors
In-reply-to: riedl@cs.purdue.EDU's message of 1 Mar 88 22:19:52 GMT

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


In article <3...@medusa.cs.purdue.edu> ri...@cs.purdue.EDU (John T Riedl) writes:

> Another feature of the choice to make semaphores/FIFOs/shared memory
> segments different from file descriptors is that select(3) presumably
> won't work with them.  How does one check the condition "is data ready
> on my queue or on my UDP port?"

In exactly the way you would expect.  How is the question "is data
ready on my queue or on my UDP port?" different from "is data ready on
my UDP port or on my other UDP port?"

Select would make perfect sense with IPC "descriptors".  A memory
segment is just like a file, always ready for reading or writing.
Message queues could respond to select just like sockets or pipes do.
I don't know about semaphores, since I still haven't thought of what
read() and write() should do to a semaphore.  But it makes sense to
be able to say "Sleep until a key is typed, or a message comes in on
this queue, or that semaphore is cleared."

Actually, select is another strong argument for having IPC descriptors.

					-=] Ford [=-

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

Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ptsfa!pacbell!att-ih!ihnp4!ho95e!wcs
From: w...@ho95e.ATT.COM (Bill.Stewart.<ho95c>)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory in BSD4.3 is lacking?
Message-ID: <2033@ho95e.ATT.COM>
Date: 4 Mar 88 19:53:37 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <2368@umd5.umd.edu>
Reply-To: w...@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 50

In article <2...@umd5.umd.edu> ch...@trantor.umd.edu (Chris Torek) writes:
:>In article <2...@umd5.umd.edu> I wrote:
:>:System V shared memory is wrong.  (Now there is a good flammable

:In article <2...@ho95e.ATT.COM> w...@ho95e.UUCP
:>Ok, I'll flame!  What's wrong with System V shared memory?

[various good responses from Chris, Mike Ditto, and others]

Yeah, I agree IPC really should be attached to the file system,
though I'm not sure whether it should look like a regular file or
like some variant on the "pipe" special file type or a character-special.
Some of the "reasonable" implementations start to look appallingly like mmap().


:>I agree that the user interface is annoying,
:(It feels like something IBM might have invented.)
Ouch, that's getting nasty :-)!

:Additionally, the total number of shared pages allowed is, I believe,
:compiled into the kernel.
It's at least configurable.  On some architectures, with ancient or bizarre
MMUs, it's tough to be flexible.

:Finally, there is, it seems, no way to have sbrk and shm*
:co-operate.
This doesn't bother me much - sbrk is inherently dealing with a different
memory space.  But it *would* be nice to have malloc() able to use shm.

:The future BSD shared memory will cure all of these
:defects, or at least we think so....
If you do it right, it may be possible to write a System-V IPC emulation
library, to preserve existing software.

			Bill Stewart, ho95c!wcs

--

:[what *are* all those numbers in your name, anyway? :-) ]
:(46323-Bill.Stewart,2G218,x0705,) writes:
  ^department       ^room ^phone-extension
The standard AT&T Bell Labs Comp. Center format for the gcos field is
	11111-name(ABC123)1111
	^dept      ^acct# ^printerbin
The news software drops the account and printer bin.  My department
has extended the format a bit; we long ago added ",room-number,phone-extension"
(see 4.1BSD passwd(5) - but we don't expand E and C to Evans and Cory);
our current administrators have recently added a <home-machine> field.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!jgm
From: j...@K.GP.CS.CMU.EDU (John Myers)
Newsgroups: comp.unix.wizards
Subject: BSD Unix domain sockets (was Re: Here's the flame everyone's asking for)
Message-ID: <1082@PT.CS.CMU.EDU>
Date: 9 Mar 88 23:19:56 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <43@kenobi.UUCP> <997@PT.CS.CMU.EDU> <47@kenobi.UUCP>
Sender: netn...@PT.CS.CMU.EDU
Organization: System/Technology Development Corp.
Lines: 41

In article <4...@kenobi.UUCP> f...@kenobi.UUCP (Mike Ditto) writes:
>In article <9...@PT.CS.CMU.EDU> j...@K.GP.CS.CMU.EDU (John Myers) writes:
>> [...]
>> Then why the heck can't you open(2) a BSD unix domain socket? [...]
>
>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"?  [...]

On a 4.3 system (IBM RT/PC), I tried binding an AF_UNIX socket to
"/foo/bar/baz" and got ENOENT.  I was also able to bind a socket to
"//tmp/foo" and connect to it by specifying "/tmp/foo".

I don't see why sockets shouldn't be in the filesystem.  They can be
read from and they can be written to.  That's more than can be said
for some of the things in /dev.  If they could be opened, they would
be almost as useful as System V named pipes.

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

Yes, this is inconsistent.  The problem I am addressing is that when a
process binds a UNIX domain socket and then exits, there is this
useless zombie socket which gets left behind.  Attemting to bind to it
gets EADDRINUSE.  Attempting to connect to it gets ECONNREFUSED.  The
only reasonable thing that one can do with it is unlink it.

Perhaps a more reasonable behavior would be to have a bind to an
existing socket address succeed if no process owns a socket with that
address.

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

Path: utzoo!mnetor!uunet!husc6!mailrus!ames!oliveb!pyramid!uccba!hal!ncoast!allbery
From: allb...@ncoast.UUCP (Brandon Allbery)
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: <7507@ncoast.UUCP>
Date: 15 Mar 88 21:58:37 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <43@kenobi.UUCP> <997@PT.CS.CMU.EDU> <47@kenobi.UUCP>
Reply-To: allb...@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 21

As quoted from <4...@kenobi.UUCP> by f...@kenobi.UUCP (Mike Ditto):
+---------------
| In article <9...@PT.CS.CMU.EDU> j...@5555tK.GP.CS.CMU.EDU (John Myers) writes:
| > In article <4...@kenobi.UUCP> f...@kenobi.UUCP (Mike Ditto) writes:
| > 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
+---------------

Ah, but this is *exactly* the same as System V IPC!  Make up your minds:
why is a BSD socket not supposed to be in the file namespace, but System V IPC
(in particular, message queues and semaphores) is flamed for it?  (I will not
yet concede the point with shared memory:  the Sequent method sounds best to
me, but then why does only Sequent use it?)
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery

Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: ch...@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: IPC namespace
Message-ID: <10684@mimsy.UUCP>
Date: 16 Mar 88 23:17:47 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <7507@ncoast.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 11

In article <7...@ncoast.UUCP> allb...@ncoast.UUCP (Brandon Allbery) writes:
>... Make up your minds: why is a BSD socket not supposed to be in
>the file namespace, but System V IPC (in particular, message queues
>and semaphores) is flamed for it?

AF_UNIX sockets are and should be in the file system space, but
the implementation is kludgey and incomplete.  They should be
(and, I predict, will be) reworked to fix this.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	ch...@mimsy.umd.edu	Path:	uunet!mimsy!chris

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.