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
