I'm planning to put another solid day or two into Shambhala this
weekend. Aside from fixing any open bugs which may come up, I've got
three things I'm thinking about; the last two at least have been on my
TODO list for a while, but some of them do involve (minor)
incompatible changes to the API.
If I get all this done (and perhaps even if I don't), I'm strongly
considering a feature freeze on the server core and the current module
set until the first public release after that (new modules would be
fine). If anyone thinks there's something wrong with the plan, please
let me know...
1) Attempt the change in handling of timeouts and client aborts which
I discussed earlier this week --- don't immediately longjmp() out
of module code back to http_main(); just put the connection in an
aborted state. This means that whatever code that the module may
need to clean up its work in progress will still run. (This should
make integration with the run time systems for languages other than
C a little easier, and give module writers generally a somewhat
less threatening environment).
2) Give modules a one-time initialization function, to be called once
at start time (or when the module is first loaded, if it's loaded
at run-time by something like mod_dld). Allow them to request new
AllowOverrides and Options bits at this time (so that a SetEnv
module could could add AllowOverride Environment, to govern the
placement of SetEnv directives in .htaccess files). I might want
to change the command tables as well to make the interface to this
facility little more graceful; right now, it's basically set up to
be convenient only if the bits in the "where-allowed" bitmask are
known at compile time.
3) A new strategy for managing the number of extant child processes:
This would involve putting up a scoreboard for the child server
processes, indicating their state. This would be a file in which
each child server has a few words to indicate its pid, and whether
it is waiting for a request. This allows us to then do the
following:
The root server periodically checks to see how many child servers
are waiting for a request. If there are fewer than some set
"MinFree" value, it forks off a *single* new child, and then goes
to sleep for a little while. Conversely, when a child is about to
wait for a new request, it checks the numbers of its fellow
children which are already waiting. If that's greater than
"MaxFree", it dies off. The aim here is to automatically spawn off
new servers if all of them are taken up with slow clients, without
ever reverting to full forking mode, and without keeping large
numbers of server processes idle when the server is just not busy
(which is bad, as they tend to get swapped out).
I figure we want at most one new child per second, to keep it from
going nuts in response to some transient load spike; I was going to
try MinFree and MaxFree of 5 and 20 respectively.
I can't promise I'll get to all these, and I certainly can't promise
they'll all work, but that's the plan. Any comments? [.I probably
won't start till Saturday noon, and whatever looks like the worst idea
can probably be put off...].
rst
weekend. Aside from fixing any open bugs which may come up, I've got
three things I'm thinking about; the last two at least have been on my
TODO list for a while, but some of them do involve (minor)
incompatible changes to the API.
If I get all this done (and perhaps even if I don't), I'm strongly
considering a feature freeze on the server core and the current module
set until the first public release after that (new modules would be
fine). If anyone thinks there's something wrong with the plan, please
let me know...
1) Attempt the change in handling of timeouts and client aborts which
I discussed earlier this week --- don't immediately longjmp() out
of module code back to http_main(); just put the connection in an
aborted state. This means that whatever code that the module may
need to clean up its work in progress will still run. (This should
make integration with the run time systems for languages other than
C a little easier, and give module writers generally a somewhat
less threatening environment).
2) Give modules a one-time initialization function, to be called once
at start time (or when the module is first loaded, if it's loaded
at run-time by something like mod_dld). Allow them to request new
AllowOverrides and Options bits at this time (so that a SetEnv
module could could add AllowOverride Environment, to govern the
placement of SetEnv directives in .htaccess files). I might want
to change the command tables as well to make the interface to this
facility little more graceful; right now, it's basically set up to
be convenient only if the bits in the "where-allowed" bitmask are
known at compile time.
3) A new strategy for managing the number of extant child processes:
This would involve putting up a scoreboard for the child server
processes, indicating their state. This would be a file in which
each child server has a few words to indicate its pid, and whether
it is waiting for a request. This allows us to then do the
following:
The root server periodically checks to see how many child servers
are waiting for a request. If there are fewer than some set
"MinFree" value, it forks off a *single* new child, and then goes
to sleep for a little while. Conversely, when a child is about to
wait for a new request, it checks the numbers of its fellow
children which are already waiting. If that's greater than
"MaxFree", it dies off. The aim here is to automatically spawn off
new servers if all of them are taken up with slow clients, without
ever reverting to full forking mode, and without keeping large
numbers of server processes idle when the server is just not busy
(which is bad, as they tend to get swapped out).
I figure we want at most one new child per second, to keep it from
going nuts in response to some transient load spike; I was going to
try MinFree and MaxFree of 5 and 20 respectively.
I can't promise I'll get to all these, and I certainly can't promise
they'll all work, but that's the plan. Any comments? [.I probably
won't start till Saturday noon, and whatever looks like the worst idea
can probably be put off...].
rst