httpd-dev mailing list archives

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