Linus Torvalds wrote:
> > * it doesn't add extra syscalls
>
> Sure it does.
>
> What do you think ioctl's are?
As I explained a few lines down from where you stopped quoting (and probably
stopped reading) the ioctl() use is just an artifact of Solaris's icky
implementation. It could and should use read(). Not an extra syscall.
> Sure, you can have multiple "poll lists" by opening /dev/poll multiple
> times, and you seem to see this as a great feature. I'm telling you that
> multiple event queues are a horrible disaster, and it's a perfect example
> of what an engineer with the "more is better" mindset comes up with.
It has nothing to do with how exciting of a feature it is. It's a matter
"hey, if you implement it with /dev/poll, you get multiple queues FOR
FREE". Those sorts of things are an indication that you've got the
implementation right. The fact that in your scheme multiple queues would
be extra work is just residue from the fact that you've got the idea wrong.
And how do you propose dealing with multi-threaded programs. Obviously for
SMP you'd want multiple threads to be able to grab events, so I guess the
"one great queue" will be shared among all the threads. But, suppose I
want to dedicate a thread to coping with a specific set of events. Hmmmm...
guess you'll need a CLONE_EVENTQUEUE flag to support that. With /dev/poll
none of this foolishness is needed - you just open tow of them and let
the threads do what they want.
> Multiple event queues are bad, because it completely breaks the notion of
> even-driven programming. How do you want to listen to them all? You can't.
Explained in detail in my mail.
> You can only listen to one event queue at a time - unless you create some
> kind of "hierarchy" of event queues, where you have one event queue that
> you wait on that contains the _other_ event queues, so that you can tell
> which one has anything pending..
No, event queues of event queues are messy in implementation. There's
nothing fundamentally wrong with them, but you need to make sure the
graph stays acyclic which is just an implementation hassle. Not enough
gain for too much code (unless someone has a beautiful algorithm)
However, it's perfectly reasonable to use select() or poll() on two event
queues. As I explained in my email, this is needed if you're already using
a library that does its own event queue based on poll or select.
> Basically, tastes differ. Everything you seem to see as an advantage of
> /dev/poll, I see as a horrible kludge.
Well, everything I see indicates that /dev/poll would be the easier of
the two interfaces to actually implement. All the added flexibility is
just gravy.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:14 EST