> A certain webserver author for a very popular webserver also thinks
> completion ports are necessary for the next generation of webservers.
> See <http://www.cs.wustl.edu/~jxh/research/research.html> for lots of
> details on various models of server architecture, and the whys and why
> nots.
> But I'm willing to be convinced that rt signals can do the job. As
long
> as I can get "wake-one" and "wake-the-most-recent-awake" semantics I
> almost don't care what they look like. Last time this thread came up
it
> looked like rt signals could do the job with maybe a tiny bit of
kernel
> help. (The "wake the most recent awake" thing is an optimization for
> L1/L2 locality.)
> poll() and select() have problems scaling to multiple threads, in
addition
> to scaling to huge numbers of fds. In a server you frequently just
want
> to ask "hey give me a completed I/O transaction so I can do some more
> processing". You don't want to know about ALL completed I/O
transactions,
> you just want one. poll(), select() (and Richard's poll2()) give
> information on all completed transactions... which leads to O(m*n)
systems
> which can be done in O(1) with completion ports.
> Dean
All within the context of the AIO thread: If you use a signal handler
(as opposed to a sigwait approach), you don't want to do much work in
it. Since you have 32 bits to work w/ in POSIX RT signals, you could
encode both an fd and a sequence # and/or a priority for that matter.
Given sufficient bits, say 18 (which still leaves PLENTY of room for
fd's), rollover shouldn't be a problem. The signal handler could then
place this onto an ordered queue to be processed (passed on to the
appropriate thread). I think this could give you a lot versatility as to
order of processing. And the nice thing, is that it avoids kernel mods
:)
BTW, SI_ASYNCIO is already defined in asm/siginfo.h.
Salut,
Steve Suson
"Keep the faith."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu