In article <199704261241.IAA24587@Twig.Rodents.Montreal.QC.CA>,
der Mouse   <mouse@Rodents.Montreal.QC.CA> wrote:
> > 	It just occurred to me, while looking at how SIGIO is
> > 	implemented, that a similar idea could be implemented for
> > 	message queues.  [...]
> 
> Could be...but is this the right way to do it?  I don't like the idea
> of having to take signal delivery overhead just to be notified of input
> on a message queue.

GWR informs me that my ideas is similar to what the POSIX realtime
extensions does, so if nothing else, it has the benefit of being close
to existing (future-existing?) practice.

I'm not sure signal delivery overhead is all that high. It might even be
less. For some of the things I'd like to be able to do, it almost
certainly is.

> Here's another idea; I have no idea how easy it would be: create a
> special device driver.  To select on a message queue, you open this
> device, do some operation (an ioctl?) to associate that instance of the
> device with the desired message queue, and then select on the file
> descriptor.  (The device would never generate any input; its only value
> would be select()/poll().  Most of its driver routines would be stubs;
> only the select routine, plus whatever is necessary to support the
> association of a message queue with each open fd onto the device, would
> actually be present.)

Hmm. This seems like more work for the programmer, and may have slightly
higher overhead (based on nothing but a quick look at the code and gut
instinct.