completing 2.0 scoreboard data set

[Stas Bekman <st...@stason.org>]

We still lack several things from the scoreboard to provide a compelete status

- httpd 2.0 doesn't maintain start/stop times in the extended status mode

This feature was lost during the transition to 2.0. This breaks tools that 
relied on these features in httpd 1.3. Jim has promised to look at it 2 months 
ago, but I suppose that he didn't have the tuits to do that.

- while vhost info was added, it doesn't contain the port info, rendering the 
vhost record useless for the non named vhosts.

any objections to adding it? Should it be in a separate record (port) or 
should we just concat vhost name and port together? "name:port"?

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: completing 2.0 scoreboard data set

[Jeff Trawick <tr...@attglobal.net>]

gregames@apache.org wrote:

> Jeff Trawick wrote:
> 
>> Also, should we be allowing modules to look at the scoreboard 
>> structures directly, or indexing into the scoreboard arrays directly?  
>> If the latter were avoided, at least we could add fields to the end of 
>> process_score or worker_score without hurting modules (okay to require 
>> MPMs to be recompiled until such time that they can be dynamically 
>> loaded).
> 
> 
> we've got accessor functions - ap_get_scoreboard_(worker|parent|global) 
> - which look correct.  Why not require non-MPM modules to use those?

and MPMs would have to declare AP_MPM_PRIVATE before including scoreboard.h in 
order to see the declarations required to access the structures directly

Re: completing 2.0 scoreboard data set

[gr...@apache.org]

Jeff Trawick wrote:

> (Lots of structures aren't arranged to minimize or make available for 
> future use the inevitable padding, but the scoreboard is one where we 
> potentally have a great number of them in shared memory and also where 
> changing the size of the structure can break some modules.)
> 
> Also, should we be allowing modules to look at the scoreboard structures 
> directly, or indexing into the scoreboard arrays directly?  If the 
> latter were avoided, at least we could add fields to the end of 
> process_score or worker_score without hurting modules (okay to require 
> MPMs to be recompiled until such time that they can be dynamically loaded).

we've got accessor functions - ap_get_scoreboard_(worker|parent|global) - which 
look correct.  Why not require non-MPM modules to use those?

There shouldn't be a noticable performance hit.  I'm assuming 
ap_update_child_status* would continue to access the structures directly, which 
  won't be a problem if the base server is recompiled when the scoreboard 
structures change.

Greg

Re: completing 2.0 scoreboard data set

[Jeff Trawick <tr...@attglobal.net>]

Stas Bekman wrote:

> - httpd 2.0 doesn't maintain start/stop times in the extended status mode

add it

> - while vhost info was added, it doesn't contain the port info, 
> rendering the vhost record useless for the non named vhosts.
> 
> any objections to adding it?

none from me

> Should it be in a separate record (port)

I'd vote for a separate field.

--/--

barely related jabber:

Note that the scoreboard data structures are screwed up w.r.t. padding 
currently.  It is hard to justify adding fields to 2.0 to use some of the 
implicit padding because theoretically there may be some platform I can't test 
that doesn't insert padding and I could break binary compatibility.  For 
2.1-dev it would be nice to rearrange the fields to minimize padding and, where 
we can show there is padding on common platforms, insert reserved fields that 
we can potentially start using later without breaking binary compatibility.
(Lots of structures aren't arranged to minimize or make available for future 
use the inevitable padding, but the scoreboard is one where we potentally have 
a great number of them in shared memory and also where changing the size of the 
structure can break some modules.)

Also, should we be allowing modules to look at the scoreboard structures 
directly, or indexing into the scoreboard arrays directly?  If the latter were 
avoided, at least we could add fields to the end of process_score or 
worker_score without hurting modules (okay to require MPMs to be recompiled 
until such time that they can be dynamically loaded).