httpd-dev mailing list archives

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

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

> Jim Jagielski wrote:
>>
>> On Sep 10, 2007, at 6:37 AM, Plüm, Rüdiger, VF-Group wrote:
>>
>>>>
>>>> For example what about adding:
>>>> static APR_OPTIONAL_FN_TYPE(ap_proxy_lb_worker_size)
>>>> *proxy_lb_worker_size;
>>>> and use a void * in scoreboard and an int for the size?
>>>
>>> For me this sounds fine, but I would guess that Jim doesn't like
>>> the void * idea in the scoreboard.
>>>
>>
>> I don't mind it at all, if we use it because we don't know
>> what will be stored away or because we may use the storage
>> differently at different times. But this is never the
>> case. lb_score always is proxy_worker_stat.
>>
>>
>
> My point goes with the comment in the code:
> +++
> /* stuff which is lb specific */
> typedef proxy_worker_stat lb_score;
> +++
> A custom balancer may have a different proxy_worker_stat, so in fact
> only modules/proxy/mod_proxy_balancer.c should know what the
> proxy_worker_stat structure contains.
>

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;

If some other struct is used then lots and lots of
other code needs to be changed to make lb_score and
mod_proxy *really* opaque to each other.

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?

Again, as I said, my main issues were that (1) we
were trying to pretend that lb_score != proxy_worker_stat
when, in fact, they are and, if anyone tried to use
it otherwise, things would break nastily. So why the
weird indirection? Not elegant at all :) and (2)
I can't see creating 1k chunks for each entry when
each one really only needs ~160-200 bytes (depending
on int and other sizes) and (3) if, for some reason,
proxy_worker_stat does increase, we need to always
make sure that things sync up enough with the entry
in scoreboard.h that we really have enough space.

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.


Mime
View raw message