fdqueue in Worker MPM

[Ronald Park <ro...@cnet.com>]

I have a few question about fdqueue in the Worker MPM.

First off, is it really a queue?  Looks like a stack to me: last
in == first out.  This could lead to starvation, no?

Second: how does ap_queue_push truly block on a full 'queue' (as
it says it does in the comment)? I see blocking for the big mutex
but nothing that checks and blocks on the queue being full.  And
without that, isn't it possible for push to go out of bounds?

Thanks,
Ron
-- 
Ronald Park <ro...@cnet.com>

Re: fdqueue in Worker MPM

[Greg Ames <gr...@remulak.net>]

Ronald Park wrote:
> I have a few question about fdqueue in the Worker MPM.
> 
> First off, is it really a queue?  Looks like a stack to me: last
> in == first out.  

right

>                 This could lead to starvation, no?

no.  The listener thread blocks if there aren't any idle workers.

An advantage of using a FIFO is that it improves the odds that the variables for 
the current socket/connection will be "cache hot" (i.e. present in the CPU's L1 
data cache) when the worker thread runs.

> Second: how does ap_queue_push truly block on a full 'queue' (as
> it says it does in the comment)? 

The comment was out of date.  I just fixed it.  Thanks!

Once upon a time, the comment was accurate.  But then we realized that 
accept()ing a new connection, then blocking on the queue was a bad thing because 
it causes unnecessary latency.  Another process with some idle worker threads 
could be processing the new connection sooner.  So we split it up.

The current worker MPM reserves a worker thread, blocking if necessary, then 
issues accept(), then pushes the new connection into the queue to dispatch a 
worker.  The event MPM works the same way for new connections and also uses this 
machinery to dispatch workers for old connections, for example after waiting for 
a second request on a keepalive connection.

>                  I see blocking for the big mutex
> but nothing that checks and blocks on the queue being full.  And
> without that, isn't it possible for push to go out of bounds?

Take a look at ap_queue_info_wait_for_idler()

Greg