[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