>
>
>
> On Tue, 24 Oct 2000, Evan Jeffrey wrote:
> >
> > > 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
> >
> > You can listen to one event queue per thread.
>
> Oh, I agree.
>
> And I think something like CLONE_EVENTS would be fine - and decide
> yourself what kind of threads you want (do you want indistinguishable
> "anonymous" threads like apache, or do you want a threads that handle
> separate event queues). Or you might have a mixture of the two - for web
> serving the "accept()" event list might be a separate thing with a few
> threads doing that, while "worker threads" handle the actual IO..
All this is fine; but why force people to break up their apps
into threads?
[ from an earlier message ]
> Trust me. Multiple event queues are idiotic. Anybody who _designs_ for
> multiple event queues has some serious problems.
So, are you now saying that "serious problems" are no longer
to be had, provided that an app is chopped into threads?
If you have one queue per process, multiple queues could
be implemented in a straightforward manner. Add a "queue"
fd type and a system call to create one. Allow any queuable
fd (such as a socket) to be queued on the one implicit queue
and also to be associated with zero or one explicitly-created queues.
This would satisfy library or other code that wanted for whatever
reason to have visibility into all fds with pending events.
It would also give apps the ability to break up work amongst
disjoint portions without forcing the use of multiple threads.
This seems reasonable to implement. Or am I missing something?
gid
-
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:15 EST