httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Fri, 10 Aug 2001 06:29:38 GMT wrote:

>        dying = 1;
>   -    apr_lock_acquire(worker_thread_count_mutex);
>   -    worker_thread_count--;
>   -    if (worker_thread_count == 0) {
>   -        /* All the threads have exited, now finish the shutdown process
>   -         * by signalling the sigwait thread */
>   -        kill(ap_my_pid, SIGTERM);
>   -    }
>   -    apr_lock_release(worker_thread_count_mutex);
>   +    ap_scoreboard_image->parent[process_slot].quiescing = 1;
>   +    kill(ap_my_pid, SIGTERM);

moving the setting of quiescing here & simplifying the worker loop is
the way to go, for sure.  

But what about the kill?  I thought we had problems quite a while ago
trying to do about the same thing in threaded.  Don't we need to wait
for all the worker threads to exit before doing that, so we don't have
weird hangs? 
>        while (!workers_may_exit) {
>            ap_queue_pop(worker_queue, &csd, &ptrans);
>   +        if (!csd) {
>   +            continue;
>   +        }

what's this all about?  the only code that I see doing a push is
checking for !NULL

design concern about graceful restarts:  the queue has several
connections built up, and in comes a ! on the PoD.  It looks like we set
workers_may_exit, and the workers bail right away, before draining the
queue.  If true, we just lost connections.

Something else we may want to consider, once this becomes more stable: 
there's all those checks for workers_may_exit all over the accept loop. 
In threaded, we're pretty much forced to do that, because other threads
could be setting it at any time.  But here, the accept loop is single
threaded so some of the checks may be unneeded.


View raw message