Re: (ITS#3665) Multi-Listener Thread Support

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:42 AM 4/17/2005, David Boreham wrote:
>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
>
>The reason you don't want to do that is the context switch overhead to get the operation from
>one thread to another. For optimal performance on an SMP system the same thread should handle
>all processing through from reading the operation off the socket to sending the response back
>(and that thread should stay on the same CPU because its cache will be hot with that
>connection's context).

I note that one of the requirements of our connection manager
is to allow concurrent processing of multiple operations
on the connection.  While many clients serialize their
operations, these clients are not terrible sensitive to
latency issues.  However, where clients (such as proxies)
issue numerous operations asynchronous, it is vital that
operations progress without unnecessary blocking on
unrelated operations.

I also note that I've asked Sang to analyze a number of
different connection management approaches, on a fairly
wide range of systems (1-8 CPU systems).  So, consider this
patch as just one possible approach... and food for thought.

Kurt