httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Maintaining status tables across restart
Date Thu, 02 Sep 1999 03:22:11 GMT
On Wed, Sep 01, 1999 at 07:13:04PM -0700, Roy T. Fielding wrote:
> >> 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.

It looks like you hit the nail on the head below. I'm trying to let
modules add their own columns to the status table. 

> 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?

We did need a good way to deal wih the insane sparseness of the table;
this might do the trick, though it might make the job of an mod_status
even harder.

> 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.

All fields in the table are strings, and modules would register table
headers as well. then, mod_status would simply display one big table
(possibly split up into some smaller tables for connections on
different protocols or something; this wasn't completely worked out)

But mod_status wasn't the primary goal; hopefully, the API will be
good enough for an SNMP module as well; I just know more about writing
mod_statuses than mod_snmps.

> Actually, I'm having a real hard time justifying a need for any of this,

Well, originally, I was just planning to write code to support various
protocol modules. Protocol modules had to be able to provide custom
columns (name-based vhosts are an HTTP-specific feature) and putting
in support for arbitrary modules to do the same shouldn't be that much

> 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.

If everything is a string, this conceptually isn't too hard (though
actual implementation may be harder). The implementation I posted last
week did this for MPM-specific columns, and mod_status used them. It's
somewhat harder to do this for other modules, for those modules to 
keep this data updated, and to deal with restarts though.

> 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).

What do you mean by the extension pointer exactly? Custom status
modules would add custom code to mangle the target of that pointer?

Dropping module-maintained status entries means dropping
protocol-specific status entries, or only suporting HTTP. I'm not
opposed to eliminating feature creep in 2.0, so it's not a big deal,
but this feature would be pretty cool.

Manoj Kasichainula - manojk at io dot com -

View raw message