Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <46E6FD00.8090703@apache.org>
Date: Tue, 11 Sep 2007 22:39:28 +0200
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r573264 - /httpd/httpd/trunk/include/scoreboard.h
References: 
 <3B21A253728EA247A10A692547A271530213F713@EITO-MBX03.internal.vodafone.com>
 <46E6BDB2.9000102@gmail.com>
 <7E29E305-EF0E-4A74-8971-CDC3972390D3@jaguNET.com>
 <46E6F4DA.7000201@apache.org>
 <DA50B19F-9CF3-43CC-8127-289B527FFEA5@jaguNET.com>
In-Reply-To: <DA50B19F-9CF3-43CC-8127-289B527FFEA5@jaguNET.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


On 09/11/2007 10:18 PM, Jim Jagielski wrote:
> 
> On Sep 11, 2007, at 4:04 PM, Ruediger Pluem wrote:
> 
>>
>>
>> On 09/11/2007 06:23 PM, Jim Jagielski wrote:
>>>
>>> On Sep 11, 2007, at 12:09 PM, jean-frederic clere wrote:
>>>
>>>>>
>>>>> 1. IMHO requires a minor bump.
>>>>
>>>> Find a patch that covers all the points you raised below.
>>>>
>>>> More comments?
>>>>
>>>
>>> Requires a major bump. Also destroys all those mystical
>>
>> Curious again. Why a major bump? Because lb_score is being converted from
>> a complete type to an incomplete type?
>>
> 
> That is one reason. Another is that any module, including
> mod_proxy, which needs to create the "old" lb_score needs
> to implement ap_proxy_lb_worker_size(). If that function
> doesn't exist, then even if they implement ap_proxy_lb_workers(),
> the lb score slot will be 0 size...

Just thinking. If some module did a

sizeof(lb_score)

it will fail to compile after the patch, because lb_score is now an
incomplete type. So I guess in order to keep it backportable we
need to stick with

typedef struct lb_score lb_score;
struct lb_score {
    unsigned char data[1024];
};

The improvement would be that we do not waste space any longer
if ap_proxy_lb_worker_size() is present and that we can be sure
that enough space is present if ap_proxy_lb_worker_size() is present
and returns more than 1024.

> 
> I would say that if the code was adjusted so if
> the function did not exist, and the worker_size
> defaulted to 1024, then they would be no regressions
> for 3rd party modules, which would remove the bump and
> make it a viable 2.2 backport.

Sounds reasonable to me.  So +1 from me adjusting the patch
in a way that it defaults to 1024 if ap_proxy_lb_worker_size()
is missing.

Regards

Rüdiger