"Paul J. Reder" wrote:
>
> @@ -568,7 +579,7 @@
> apr_signal(SIGHUP, just_die);
> apr_signal(SIGTERM, just_die);
>
> - while (!ap_graceful_stop_signalled()) {
> + while ((!ap_graceful_stop_signalled()) && (!ap_idle_die_signalled())) {
>
This is part of the mainline request loop. Couldn't this be optimized
so that we don't need to check two conditions, each of which is a
function call checking two conditions, one of which is deferred_die in
both functions?
I could see moving some of the path length into the graceful
restart/shutdown code, since it doesn't run very often. It could walk
thru the scoreboard and put some appropriate DIE value into the
life_status field for each worker. The signal handler that now sets
deferred_die could set some appropriate DIE value into its own
scoreboard slot instead. Then the checks in the request loop could be
simplified to something like (scoreboard[my_slot].life_status !=
SB_WORKING). Does that make sense?
> - if (ap_graceful_stop_signalled()) {
> + if ((ap_graceful_stop_signalled()) || (ap_idle_die_signalled())) {
> clean_child_exit(0);
> }
> usr1_just_die = 1;
same comment as above.
Greg
