Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Wed, 15 Sep 1999 18:31:06 +0100 (BST) | Subject | Re: > 15,000 Simultaneous Connections |
| |
Hi,
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/
| |