[PATCH] worker MPM optimizations

[Brian Pane <bp...@pacbell.net>]

I'm posting this for comments before committing...

Here are some more changes the worker MPM code to reduce
the time spent in mutex-protected regions.

This patch takes advantage of a new property of the worker
design that resulted from Aaron's queue_info changes: the
number of connections in the queue can no longer exceed the
number of idle worker threads.

There are two changes in this patch:

  * Eliminate the use of the queue->not_full condition
    variable (because the idle thread count in queue_info
    keeps the listener from being able to overflow the queue)

  * Change the queue back to a stack.  The reason for this
    is that it reduces the cost of the push and pop operations
    to a near-minimal level.  I think it's now safe to use a
    LIFO structure again, because we can depend on there being
    enough idle threads to handle all the connections in the
    fdqueue.

--Brian

Re: [PATCH] worker MPM optimizations

[Aaron Bannert <aa...@clove.org>]

On Sun, Apr 28, 2002 at 12:03:57AM -0700, Brian Pane wrote:
> I'm posting this for comments before committing...
> 
> Here are some more changes the worker MPM code to reduce
> the time spent in mutex-protected regions.
> 
> This patch takes advantage of a new property of the worker
> design that resulted from Aaron's queue_info changes: the
> number of connections in the queue can no longer exceed the
> number of idle worker threads.
> 
> There are two changes in this patch:
> 
>  * Eliminate the use of the queue->not_full condition
>    variable (because the idle thread count in queue_info
>    keeps the listener from being able to overflow the queue)
> 
>  * Change the queue back to a stack.  The reason for this
>    is that it reduces the cost of the push and pop operations
>    to a near-minimal level.  I think it's now safe to use a
>    LIFO structure again, because we can depend on there being
>    enough idle threads to handle all the connections in the
>    fdqueue.

+1 on both accounts. I haven't tested the code, but it looks correct
from an eyeball review.

-aaron