[lkml]   [2000]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Followup to:  <>
By author: Dave Zarzycki <>
In newsgroup:
> Maybe I'm missing something, but why do you seperate out fd from the event
> structure. Why not just "int bind_event(struct event *event)"
> The only thing I might have done differently is allow for multiple event
> queues per process, and the ability to add event queues to event
> queues. But these features might not be all that useful in real life.

This could be useful if it doesn't screw up the implementation too

Pretty much, what Linus is saying is the following:

select()/poll() have one sizable cost, and that is to set up
and destroy the set of events we want to trigger on. We would
like to amortize this cost by making it persistent.

It would definitely be useful for the user to have more than one such
"event set" installed at any one time, so that you can call different
wait_for_event() [or whatever] as appropriate. However, if that means
we're doing lots of constructing and deconstructing in kernel space,
then we probably didn't gain much.

The other things I think we'd really like in a new interface is an
interface where you can explicitly avoid the "storming hordes" problem
-- if N servers is waiting for the same event, it should be at least
possible to tell the kernel to only wake up one (arbitrarily chosen)
of them, rather than all.

Finally, it would be somewhat nice to have a unified interface for
synchronous and asynchronous notification. This should be quite
easily doable by adding a call event_notify(event_set,signal) that
causes real-time signal "signal" to be raised (presumably with the
event_set as the argument), when the specified event_set triggers.


<> at work, <> in private!
"Unix gives you enough rope to shoot yourself in the foot."
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.129 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site