httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: worker mpm: can we optimize away the listener thread?
Date Thu, 29 Nov 2001 17:59:10 GMT
On Thursday 29 November 2001 09:45 am, Brian Pane wrote:
> Aaron Bannert wrote:
> >On Thu, Nov 29, 2001 at 09:20:48AM -0800, Brian Pane wrote:
> >>From a performance perspective, the two limitations that I see in
> >>the current worker implementation are:
> >> * We're basically guaranteed to have to do an extra context switch on
> >>   each connection, in order to pass the connection from the listener
> >>   thread to a worker thread.
> >> * The passing of a pool from listener to worker makes it very tricky
> >>   to optimize away all the mutexes within the pools.
> >
> >IIRC, the problem isn't so much the fact that pools may be passed around,
> >since in that respect they are already threadsafe without mutexes
> >(at least in the current CVS and in the recent "time-space tradeoff"
> >patch. I believe the actual problem as you have described it to me is
> >how destroying a pool requires that the parent be locked. Perhaps you
> >can better characterize the problem.
>
> Right--the fact that the transaction pools are children of a pool
> owned by the listener thread means that we have to do locking when
> we destroy a transaction pool (to avoid race conditions when unregistering
> it from its parent).

I'm not sure this will fix the problem, but can't we fix this with one more level
of indirection?

Basically, the listener thread would have a pool of pools, one per thread.
Instead of creating the transaction pool off of the man listener pool, it creates
the pool of pools off the listener pool, and the transaction pool off the next
pool in the pool of pools.

          listener

sub-pool1	sub-pool2	sub-pool3

trans-pool	trans-pool	trans-pool

The sub-pools are long-lived, as long as the listener pool. By moving the
trans-pool to under the sub-pool, and only allowing one trans-pool off
each sub-pool at a time, we remove the race-condition, and can remove
the lock.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message