httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: [Patch]: Suggested patch to fix perform_idle_server_cleanup window.
Date Fri, 23 Mar 2001 19:09:44 GMT
"Paul J. Reder" wrote:
> These two functions could easily be merged, 

OK, that sounds like a good first step.  But better still would be to
make this so simple for the mainline code that no function or macro is
called for.  Just test one variable.
> >
> > 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?
> Are you suggesting merging the restart (generation) and idle cleanup flags?

I'm suggesting that the question, "Should I keep working?" is very
simple conceptually, so the code to perform the test in the main loop
should be dead simple.  We can use your new field in the worker's slot
of the scoreboard as the one and only place that needs to be checked to
answer such a question.  If we do that, there's no need for function
calls or macros, which makes things simpler still.  Yes, we would have
to make the code that initiates graceful restart a tiny bit more
complex, but I think that's a fair tradeoff.  The generation numbers can
remain separate, but unused for this purpose.

Without your patch, we are touching 4 separate variables (deferred_die,
ap_my_generation, ap_scoreboard_image, and
ap_scoreboard_image->global.running_generation ) to answer "Should I
keep working?".  Worse case, that's 4 data cache lines that must be
either already present in the cache or fetched, at two different spots
in the request loop separated by what could be a long time delay.  That
seems like a lot, so I am advocating making the situation better by
reducing rather than increasing the number of variables accessed.  


View raw message