httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: [PATCH] lingering close and event
Date Sat, 07 May 2011 23:49:03 GMT
hey I like the concept a lot!  a quick peek at 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 <> 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.


View raw message