Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!texbell!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.questions Subject: Re: Summary: Is there a select()-like call for message queues? Message-ID: Date: 12 Jan 90 23:08:42 GMT References: <1826@xyzzy.UUCP> <11925@smoke.BRL.MIL> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 62 > >... 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. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'