httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: Maintaining status tables across restart
Date Thu, 02 Sep 1999 02:13:04 GMT
>> Why not just have a status field that indicates the child's generation?
>> In other words, why does the scoreboard have to change across generations
>> if it is shared memory and a graceful restart?
>
>This is possible, but then, we have to create an arbitrary limit on
>the "length" of a row, i.e. how much space any row can take up in the
>shared memory table. Since rows can actually change size between
>restarts, the last thing we want to worry about is shared memory
>fragmentation, so we have to align the rows on these boundaries.

Ah, so that's the reason -- changing row size due to a config change.
But Apache 1.3.9 has a fixed, compile-time record size, so I'd have
to understand what dynamicity is being added to 2.0 that would cause
that to be a concern.

>Is this an acceptable limitation? It's not *too* bad; the worst it can
>mean is that we tell users to recompile with a higher
>HARD_ROW_LENGTH_LIMIT.

We already have that.  Instead of letting modules add fields directly
to the scoreboard, which would introduce a host of messy problems,
how about adding a single shared-memory pointer field to a per-child
shared-memory table of key-value pairs?  It would be slower for children
actually using that field for status, but how often is that going to occur?
Besides, your status displayer is going to need something to indicate
what to do with each extended field item.

Actually, I'm having a real hard time justifying a need for any of this,
since having dynamic fields doesn't change the fact that only a dynamic
status module could display them, which means the status module needs to
know the structure of the shared memory fields anyway.  Just make it a
compile-time include with an extension pointer in the scoreboard (and
abuse anyone who wants to compile-in more than one extended status module).

....Roy

Mime
View raw message