kan@dg-rtp.dg.com (Victor Kan) (01/05/90)
Here's a summary of replies to a question I posted a little while ago. I asked if there's an analog to select() that works on message queue ids rather than just file descriptors. The general consensus is that there is no such beast on Unix. BUT, IBM of all companies lets you use select() on message queue ids. AIX! Who would have thought? I would guess Carnegie Mellon's (RT/PC Central) relationship with IBM may have brought about this innovation but no one's saying. The only non-Unix OS mentioned in any of the replies was Trollius from Cornell. From: guy@auspex.com (Guy Harris) Not in standard UNIX. One more reason why "System V IPC" (message queues, semaphores, shared memory) is a bit of a crock; the mechanisms are all stuck on the side of UNIX. From: beers@tcgould.TN.CORNELL.EDU (Jim Beers) We, were just discussing this a couple of weeks ago around here, at the Trollius group. We do not have such a call in Trollius, a message passing operating system, and were told it is an obvious feature. Intel has a call, iprobe I think it is called. So we are now considering adding something like this into Trollius, but there are some questions about whether or no it should be included. From: mark@parc.xerox.com (Mark Weiser) On SunOS (and all new System V conforming systems) there is the new "poll" syst\ em call. [My man page for poll() mentions only STREAMS - vk]. From: tim@sybase.com (Tim Wood) I haven't used those OS's myself, nor do I know in detail how VMS or AOS do this (except I'm pretty certain VMS supports this concept). I would suggest, instead of using msgsend/recv, try using sockets in the UNIX domain, i.e. socets which have file system names. Then you should be able to select() on their file descriptors. Does your version of UNIX support this feature? I believe it orginated in the BSD 4.x socket library. From: baur@venice.sedd.trw.com (Steven L. Baur) You Lose!!!!!!!!! (Sorry) Message Queues have no equivalent to the select(2) system call. And further more, most System V's have no time resolution below one second. Good luck, but you are fighting a losing (or lost) battle. (I run system V boxes at home and sorely miss the loss of unix domain sockets, struct timeval, select, and job control). From: jason@cs.utexas.edu (Jason Levitt) Under AIX 2.2.1 on the IBM RT, the select(2) system call works with message queues. As far as I know, though, this is the only implementation. IBM, for some strange reason, has also chosen to implement distributed message queues as well i.e. your local msg queue id can actually be attached to a msg queue on another machine in the LAN. Anyway, if you're using the RT, you *can* use select(2) with message queues! | Victor Kan | I speak only for myself. | *** | Data General Corporation | Edito cum Emacs, ergo sum. | **** | 62 T.W. Alexander Drive | Columbia Lions Win, 9 October 1988 for | **** %%%% | RTP, NC 27709 | a record of 1-44. Way to go, Lions! | *** %%%
prc@erbe.se (Robert Claeson) (01/09/90)
> From: baur@venice.sedd.trw.com (Steven L. Baur) > > Message Queues have no equivalent to the select(2) system call. And > further more, most System V's have no time resolution below one second. Using the poll() system call with no stream id's specified (just like the select() call), you can have millisecond resolution delays (just like with select()). I can send the code to anyone interested. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
peter@ficc.uu.net (Peter da Silva) (01/10/90)
Yeh, it's a bummer. For years a buddy of mine said that this and asynch
I/O was sorely needed in UNIX, but only in the past few years did I come
around. You should be able to do a poll/select on *any* file descriptor
or combination thereof. Not only that, but you should be able to post
a read() without waiting. This would be a much cleaner technique than
either select() or poll(), and would allow all sorts of nice epiphenomena.
For example, you could explictly read-ahead on a raw device...
(da Silva real-time-UNIX-hooks rant # 45)
--
_--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/ \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>
\_.--._/
v "Have you hugged your wolf today?" `-_-'gwyn@smoke.BRL.MIL (Doug Gwyn) (01/10/90)
In article <G3:5JFxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >... 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".
peter@ficc.uu.net (Peter da Silva) (01/13/90)
> >... 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@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/15/90)
In article <ZQ01CS1xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
-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.
That would be fine, and there are a handful of people working on such
an approach. Unfortunately there are many more working on adding warts.
-Let's add 4 new system calls: aread, awrite, await, and status.
-This doesn't break any existing programs, nor does it do any injury to
-the design goals of UNIX.
Yes, it does! Go back and read what I said in my previous message.peter@ficc.uu.net (Peter da Silva) (01/16/90)
> -Let's add 4 new system calls: aread, awrite, await, and status. > -This doesn't break any existing programs, nor does it do any injury to > -the design goals of UNIX. > Yes, it does! Go back and read what I said in my previous message. I'm sorry, but other than the assertion that asynchronous I/O is itself a violation of the design goals I don't see anything that would lead to this conclusion. And I don't see that that, in and of itself, is a problem in the face of all the poor asynchronous I/O models that are spreading like gangrene through the UNIX world. At the worst it's a matter of choosing the lesser of two necessary evils. I mean you seem to agree that *allowing* asynchronous I/O is a good idea. Can you come up with a cleaner model? I'd love to see it. I would agree that asynchronous I/O makes for problems in the traditional big-kernel-with-ad-hoc-coroutines *implementation* of UNIX. But that's another story. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'