"Bill Stoddard" <[EMAIL PROTECTED]> writes:
(I would have quoted but the text is way out at columns 89-92 or so)
I think the patch is fine, but I can't help but suspect that some of
the pain you are alleviating is caused by the known problem where the
listener thread can accept connections when there are no spare workers
to handle it.
Yes, the listener thread may do a little more at startup than a worker
thread, but if it knew better than to go grab connections it couldn't
service then would it really cause the system to thrash any more than
it is going to thrash anyway in order to get those threads created and
dispatched?
> Index: worker.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v
> retrieving revision 1.117
> diff -u -r1.117 worker.c
> --- worker.c 18 Apr 2002 17:46:20 -0000 1.117
> +++ worker.c 26 Apr 2002 14:50:43 -0000
> @@ -948,6 +948,7 @@
> apr_status_t rv;
> int i;
> int threads_created = 0;
> + int listener_started = 0;
> int loops;
> int prev_threads_created;
>
> @@ -999,16 +1000,18 @@
> clean_child_exit(APEXIT_CHILDFATAL);
> }
> threads_created++;
> - if (threads_created == 1) {
> - /* now that we have a worker thread, it makes sense to create
> - * a listener thread (we don't want a listener without a worker!)
> - */
> - create_listener_thread(ts);
> - }
> +
> + }
> + /* Start the listener only when there are workers available */
> + if (!listener_started && threads_created) {
> + create_listener_thread(ts);
> + listener_started = 1;
> }
> +
> if (start_thread_may_exit || threads_created == ap_threads_per_child) {
> break;
> }
> +
> /* wait for previous generation to clean up an entry */
> apr_sleep(1 * APR_USEC_PER_SEC);
> ++loops;
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
