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: 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 <3371@medusa.cs.purdue.edu> riedl@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%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