Summary: Is there a select()-like call for message queues?

[Peter da Silva]

> >... you should be able to post a read() without waiting.

> There's something you should understand about UNIX:
> A fundamental goal of its design was to convert real-world asynchronity
> into apparent synchronity so far as application programs are concerned.
> It succeeded at this quite well.
> If you want to change the design goals, you'll get better results by
> properly designing a new operating system taking the different goals
> into account than by trying to graft foreign notions into the existing
> structure.
> The technical name for such grafts is "warts".

Well, thank you for this positive input, Doug. I'm so glad that there are
folks out there ready to jump on people who dare to suggest that UNIX would
benefit from this or that facility. How about explaining this somewhat
brief message a bit more fully?

First of all, before I start in on a clarification, I'd like to note that
this particular "wart", as you put it, has been added in many inconsistent
ways to many versions of the system. The fact that different variants of
UNIX handle asynchronous I/O in different ways and for different types of
devices is the cause of a lot of porting problems.

Perhaps you would like to abolish select(), poll(), VMIN, VTIME, and other
such "warts". Actually, I'd love to do that... but only to replace them
with one of those simple, clean, uniform, device independent concepts that
UNIX is famous for. Remember device-independence? It's a fundamental
design goal of UNIX.

You see, there's a need for these facilities.

OK, now how about this:

Let's add 4 new system calls: aread, awrite, await, and status.

aread and awrite take the same arguments as read and write. They return
0 for success, -1 for failure. They could be mapped on to read/write
by some sort of fcntl (say, fcntl(fd, F_SETFL, O_ASYNC)) if you don't
want extra system calls. I'd rather not do that at this point, just
on the principle of least astonishment.

await takes a set of file descriptors. The form of this set is not
strictly important, but the address of a multi-word bitmap is traditional
for calls of this type both under UNIX and in other operating systems.
It returns an indication of what file descriptors have completed I/O. This
could be another bitmap, or a single file descriptor (in which case you
could call it repeatedly), or it could modify the input bitmap.

status takes a file descriptor and returns the result code that would have
been returned from read/write if this wasn't an asyncronous call.

This doesn't break any existing programs, nor does it do any injury to
the design goals of UNIX. What it does is allow the user to perform
asynchronous I/O operations cleanly, consistently, and in a device-
independent manner.

Now I realise that this shares quite a bit of similarity with poll()
and select(), but it's a little cleaner than either and should be
applicable to all devices.

In conclusion, the warts are there. I'm suggesting replacing them with
something more elegant.
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter at ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'