Jim Jagielski wrote:
>
> Greg Ames wrote:
> > understand your concern, but it just requires code.
>
> That's the rub. :) It would involve, at least to my eye, some
> non-trivial adjustments to how the whole parent process handles
> generations. Right now, we change a value in the scoreboard
> and that's it. With this, we need to control and manage 2 (or possibly
> more) scoreboards, at least for some period of time, while the
> graceful restart is monkeying around. If the main reason why is
> to "save some scoreboard memory" I don't think the added complexity
> or cycles would be worth it... Be that all said, if this *is* added,
> I could see some future uses for it.
The current generation code needs some cleanup. Jeff Trawick already did
a little, but there is still more to go. It is not currently used in a
consistent manner among the mpms and, in fact, is not used at all in prefork.
There would *not* need to be 2 or more scoreboards. The scoreboard would be
a linked list. The top level list of process_score elements can contain
processes from different generations. The older generations would be at
the end of the list, processes from the newest generation are at the head of
the list.
The main reason is to make mpms work reasonably when max_requests_per_child
is set to anything other than 0. This mostly impacts the threaded mpm which
currently works unacceptably. Any of the other aspects that people are
currently side tracked on (saving memory, removing HARD_SERVER_LIMIT, etc.)
are possible side benefits but not the primary problem being solved.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
