"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. Thanks, Greg
