From: Jeff Trawick <trawick@apache.org>
Date: Fri, 22 Mar 2002 03:43:22 +0000 (+0000)
Subject: document yet another worker MPM glitch
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d8957c79f3ad19e297d4ed08801bdd9638b16787;p=apache

document yet another worker MPM glitch


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94117 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/server/mpm/worker/worker.c b/server/mpm/worker/worker.c
index b3b3b1d6b0..dbc1ae8ec9 100644
--- a/server/mpm/worker/worker.c
+++ b/server/mpm/worker/worker.c
@@ -926,6 +926,14 @@ static void * APR_THREAD_FUNC start_threads(apr_thread_t *thd, void *dummy)
     my_info->pid = my_child_num;
     my_info->tid = i;
     my_info->sd = 0;
+
+    /* XXX we shouldn't create the listener thread until we have at least
+     *     one worker thread...  for now I'll blame this bug for some very
+     *     rare hung connections I've seen during restart testing
+     *     (I've also seen cases where a child process starts but is
+     *     never able to take over worker thread slots, so the theory
+     *     does make sense.)  Jeff
+     */
     rv = apr_thread_create(&ts->listener, thread_attr, listener_thread,
                            my_info, pchild);
     if (rv != APR_SUCCESS) {