httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r1068581 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.h mod_proxy_balancer.c mod_proxy_ftp.c proxy_util.c
Date Wed, 09 Feb 2011 13:04:11 GMT

On Feb 9, 2011, at 2:33 AM, Ruediger Pluem wrote:
> Don't we need to protect the address cache for unbalanced workers as well by a thread

I don't think we do... I'll smoke test to make sure.

> Hm, why don't we need to protect the data in the shared mem like candidate->s->elected
> or the other elements that are touched by the finder with a global lock?
>> -    if ((rv = PROXY_GLOBAL_LOCK(balancer)) != APR_SUCCESS) {
>> +    if ((rv = PROXY_THREAD_UNLOCK(balancer)) != APR_SUCCESS) {
> I assume you wanted PROXY_THREAD_LOCK instead of PROXY_THREAD_UNLOCK :-)

Yeah ;)

> Same question as above: We change data in the shared mem. So why only a thread lock?

The long and short of it is that using only a thread lock is
pretty much what we've used before... it's know that it
provides some protection but not full protection. The trade
off is whether or not the overhead of a global mutex is
worth it... most of the time it just means some possible
errors when updating the LB factors which, over time,
evens out anyway.

The issue know is to find those places where it causes
*real* problems and global mutex those areas...
View raw message