On Tue, 24 Oct 2000, Mitchell Blank Jr wrote:
> I think everyone should take a timeout and look at Solaris 8's /dev/poll
> interface. This discussion is reinventing the wheel, the lever, and the
> inclined plane.
>
> http://docs.sun.com/ab2/coll.40.6/REFMAN7/@Ab2PageView/55123
>
> I think this is a lot cleaner than your approach:
You must be kidding.
/dev/poll is the interface from _hell_. It's absolutely disgusting.
> * it doesn't add extra syscalls
Sure it does.
What do you think ioctl's are? Every single ioctl number is an extra
system call. It's just indirected inside the device driver instead of at
the normal system call entry point. The advantage? It's noticeably slower
than a real system call.
And the final reason why /dev/poll should just go away: not only is the
interface ugly, but it's hard to use too. It's really hard to mix
different users of /dev/poll - you'll have to create a whole new event
structure around it.
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.
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.
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..
Trust me. Multiple event queues are idiotic. Anybody who _designs_ for
multiple event queues has some serious problems.
Basically, tastes differ. Everything you seem to see as an advantage of
/dev/poll, I see as a horrible kludge.
Linus
-
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:13 EST