hey I like the concept a lot! a quick peek at
http://apache.org/server-status shows 15 Cs for threads tied up in lingering
close, something like 50 Keepalive threads, and only 13 threads actually
reading or writing.
On Mon, Apr 25, 2011 at 8:53 PM, Jeff Trawick <traw...@gmail.com> wrote:
> has anyone played with this before? I've seen it mentioned, and joe s
> had a patch to create a linger thread for worker back in 2004
>
> + apr_thread_mutex_lock(timeout_mutex);
+ APR_RING_INSERT_TAIL(&recv_fin_timeout_head, cs,
conn_state_t, timeout_list);
+ apr_thread_mutex_unlock(timeout_mutex);
I see where the cs is removed from the ring for the timeout flow. but what
about for the normal non-timeout flow?
rv = apr_pollset_create(&event_pollset,
- threads_per_child,
+ threads_per_child, /* XXX don't we need
more, to handle
+ * connections in K-A
or lingering
+ * close?
+ */
IIRC the second arg to apr_pollset_create determines the size of the revents
array used to report ready file descriptors. If there are ever more ready
fds than slots in the array, it's no big deal. They get reported as ready
on the next apr_pollset_poll call. So using threads_per_child is just
picking a number out of the air which happens to go up automatically as the
worker process is configured for higher workloads.
Greg
