[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3665) Multi-Listener Thread Support
Kurt D. Zeilenga wrote:
At 08:24 AM 4/17/2005, Howard Chu wrote:
Overall I'm not totally convinced that this is the right place to be dividing the labor. It would make more sense to me to keep the single listener, and hand off each triggered event to the thread pool, so that reading and parsing is multithreaded.
I note that a tricky part of a lightweight dispatcher is dealing
with selects on the listening descriptors. If you queue only
one worker thread on each selected descriptor, you effectively
serialize accepts/connection building... and that's a major
bottle neck today in handling large number of short lived
sessions. So, the dispatcher needs some tricks to avoid
serialization of accepts/connection building.
Since the number of listeners is generally small, it would be reasonable
to devote a thread to each, sitting in an accept() call and completely
avoiding the use of select() there. Then those threads could begin
building connections as fast as the kernel can deliver connect events.
Alternatively, use two threads, one for accept/connection events and one
for all the rest. Ultimately the serialization will still occur, because
the connection structures still need mutex'd accesses. To avoid that
would require splitting the single connection table into multiple lists,
dedicated to separate threads, so we can guarantee that no accesses will
collide. That might be worth doing, but it would be a pretty significant
rewrite.
As I noted in my response to David, Sang is actually exploring
a number of different approaches. I should also note that Sang
will be looking a one or two lightweight dispatcher approaches.
It should be interesting to see which approach demonstrates itself
to be generally "best".
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support