httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r573264 - /httpd/httpd/trunk/include/scoreboard.h
Date Mon, 10 Sep 2007 14:35:15 GMT

On Sep 10, 2007, at 10:13 AM, jean-frederic clere wrote:

> Jim Jagielski wrote:
>> I'm not sure what you mean. mod_proxy does, in child_init,
>> the calls to create those scoreboard entries. It does
>> so via ap_proxy_initialize_worker_share(). No matter
>> what, the ->s is set to:
>>    worker->s = (proxy_worker_stat *)score;
> Well below that, the lines:
>        if (worker->route) {
>         strcpy(worker->s->route, worker->route);
>     }
> shows cleary the problem.

Well, not that clearly because I have no idea how
it does so.

>> Or are you suggesting that some other "balancer"
>> which completely bypasses mod_proxy (and, in fact,
>> replaces mod_proxy) could be using that scoreboard
>> entry?
> Well such a tool could use its own shared memory but yes making  
> lb_score
> opaque in scoreboard.c will allow to write such modules.

Agreed. But I would guess that anyone who would do
so would create their own shared-memory allocation
outside of the scoreboard anyway... and see below
about another point.

>> And once again, the *real* fix is changing our usage
>> and allocation of the scoreboard, something set for
>> 3.0. If people want that for 2.4, then cool.
> One thing is what we store another thing is where we store it.
> We are discussing what we store ;-)

What we store in that location is proxy_worker_stat. Nothing
else. AFAIK, no one else uses it for any other purpose.
If they do then it is clearly a storage location that
Apache's mod_proxy uses for proxy_worker_stat and the
balancer code.

I can't see wasting all this time saying "OK, right
now it's not really opaque enough so let's do all
this moving and hacking to make it so" when (1)
we can't say it's a generic scoreboard storage
space because it can be used only by one module
exclusively... making it opaque and therefore "usable
by anyone" also implies some sort of "but only one
person can use it at a time"... Can't do the 1st
without bothering with the 2nd and (2) this is hardly
specific to mod_proxy; Whatever the solution is needs
to be generic enough for anyone and everyone to use
which, for sure, will change the API in which case
what we do for *this* API is no longer applicable.

Holy moley... let's just change it back to the way
it was and get *on* with it... geez.

View raw message