On Sat, Apr 30, 2016 at 1:04 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>
> How about:
>
> Index: server/mpm/event/event.c
> ===================================================================
> --- server/mpm/event/event.c (revision 1741696)
> +++ server/mpm/event/event.c (working copy)
> @@ -2857,7 +2857,7 @@ static void perform_idle_server_maintenance(int ch
> (status == SERVER_GRACEFUL);
> any_dead_threads = any_dead_threads || (status == SERVER_DEAD);
> all_dead_threads = all_dead_threads &&
> - (status == SERVER_DEAD || status == SERVER_GRACEFUL);
> + (status == SERVER_DEAD);
>
> /* We consider a starting server as idle because we started it
> * at least a cycle ago, and if it still hasn't finished starting
> _
>
> AIUI, that would (re)use *in priority* scoreboard entries of processes
> *fully* idle.
> So possibly admins could configure ServerLimit = N *
> (MaxRequestWorkers / ThreadsPerChild), where N would be the number of
> graceful restarts expected to not mix worker entries of old/new
> generation processes.
Hmm, not that easy actually.
perform_idle_server_maintenance() is currently based on
ap_daemons_limit processes (as possibly are codes using
AP_MPMQ_MAX_DAEMONS), not on server_limit.
Using the spare "server_limit - ap_daemons_limit" room at runtime
would require changing ap_daemons_limit dynamically/accordingly...
Is setting "AP_MPMQ_MAX_DAEMONS = server_limit" an option with
mpm_{event,worker}, so that we could make dynamic ap_daemons_limit
internal to those MPMs, whereas AP_MPMQ_MAX_DAEMONS users would
continue to "work"?
