On Tue, 14 Sep 1999 23:39:01 -0700 (PDT), Gideon Glass
<gid@cobaltnet.com> said:
> I believe that the API presented in the Banga/Mogul/Druschel paper
> lets you retrieve N events at one time, in order to amortize the cost
> of the dequeuing operation.
Fine, I'd be more than happy to see us add a sigwaitinfos() call to
pass multiple siginfos at once. I'd rather do that than change the
underlying siginfo mechanism that already exists in Linux.
> Advantanges over sigwaitinfo():
> - can dequeue multiple events in one call
So fix sigwaitinfo, don't redo from scratch.
> - Queues would be automatically shared -- iff file descriptors are shared.
Signals can do this in principle. They already do, in fact, but the
current implementation is too gross --- I don't want to talk about it
right now. :)
> - Since there is no implicit per-process state (e.g. signal handlers), we
> avoid the need for library and application code to fight it out over
> who gets what signals.
It doesn't address the underlying issue that *all* of these models
with explicit event dequeuing rely on a single dequeue call being able
to handle events from any file descriptor. It's just like select: if
you have a select loop, then all your libraries need to have
registered their fds with whatever code is doing the select loop
(think about the X core event loop, for example).
With a signal dequeuing mechanism, your application is going to get
signals destined for various library components if libraries are using
the same mechanism. Sorry, but there's no magic wand here. In fact,
the *only* mechanism I've seen which can let a library do its
event-based work transparently is the signal model: if you want
non-blocking IO on some set of fds, the library can set up its own
signal handler for those fds and deal with that signal transparently
to the rest of the application.
The event queueing models simply don't have any support for this at
all.
Given that the current glibc does have a way to farm out rt signums to
different components, the argument that completion ports somehow deal
with libraries better than signals appears to be totally bogus.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/