httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rici Lake <r...@ricilake.net>
Subject Re: RFC: Who owns a passed brigade?
Date Fri, 22 Apr 2005 00:05:34 GMT

On 21-Apr-05, at 5:51 PM, Nick Kew wrote:

> Rici Lake wrote:
>
>> FWIW, I think the (apparent) practice, where the caller relinquishes
>> ownership of the buckets but not the brigade itself, is more efficient
>> since it avoids a lot of brigade construction and destruction.
>
> Agreed.  And it works for any situation, as either party can do a
> cleanup to keep resource-use down, and a cleaned up brigade is not
> too big to wait for pool cleanup.

"Either party can do a cleanup" does not give either party the 
responsibility. If neither party did the cleanup, that would be a 
problem. Lack of clear responsibility is always a problem, and not just 
with computer programs.

I favour having ap_pass_brigade do it. If the brigade must be cleaned 
before ap_pass_brigade returns, then it might as well be done by 
ap_pass_brigade.

However, I think it is a fallacy that a cleaned-up brigade is not too 
big to wait for pool cleanup. The brigade itself is about four 
pointers; and the corresponding pool cleanup is another four pointers, 
so that's a total of around 32 bytes, not a lot. But suppose that a 
brigade is created for every 8k of filtered data, and you run 4 GB of 
data through that without destroying any brigades. That's half a 
million brigades and half a million registered cleanups (linearly 
searched on kill, so you better hope the cleanups are destroyed in the 
right order).

See <http://issues.apache.org/bugzilla/show_bug.cgi?id=23567> and 
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33382>; Paul 
Querna's patch to fix the latter bug clearly shows how you can drown in 
empty brigades (or rather, how to avoid drowning in them).

> Logically it makes a lot of sense
> to run brigade_cleanup once per pass_brigade, and it's harmless if
> the brigade was already cleaned.
>
>> But it's
>> a slightly odd convention.
>>
>> I don't think it makes that much difference, provided that there is a
>> clear statement and that everyone follows it.
>
> Creator-is-responsible is simple logic.  Other options are more complex
> and bug-prone, as we then have issues like whether to destroy on
> every call or only on EOS.  Or maybe on FLUSH ....
> Also, creator-is-responsible is a logic that can apply symmetrically
> to both input and output filters without mindbending.

I didn't mean to say that "creator-is-responsible" is odd. What I meant 
was that it is odd that ownership of the buckets gets transfered but 
not of the brigades. Creator-is-responsible is fine. Transferred 
ownership is fine. Part of one and part the other is odd. Not 
unworkable -- just odd. And thus in need of clear documentation.

> Dropping destroy from the API altogether and leaving that to the pool
> would also work, AFAICS.

-1, too fragile. See above bugzillas.


Mime
View raw message