httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rici Lake <>
Subject Pool buckets, transient buckets and bucket_setaside
Date Mon, 25 Apr 2005 21:24:47 GMT
Why do pool buckets do an automatic setaside? Should they?

No other bucket type does this; consequently, if you want to hold on to 
a bucket beyond the scope of the call in which you received the 
brigade, you must explicitly call bucket_setaside.

Without examining the bucket type, a practice which should normally be 
discouraged, it is impossible to know whether a given bucket will 
auto-setaside or not; consequently, bucket_setaside should always be 
called (possibly via ap_save_brigade).

So it would seem that either all bucket types should do auto-setaside 
or that none of them should. It would undoubtedly be convenient if all 
buckets did this -- it would remove the necessity for ap_save_brigade 
-- but I believe there is an issue with the model.

Consider a pool bucket which is placed into an existing brigade. If 
this brigade is not explicitly cleaned up, which would defuse the pool 
bucket's setaside mechanism, then both the brigade and the pool 
bucket's cleanup functions will run when the pool is cleaned up. The 
bucket's cleanup function is likely to run first, however, since it is 
likely to be newer than the brigade it was put into. That will create 
an unnecessary heap copy of the bucket, which will then be free'd when 
the pool cleanup for the brigade runs, slightly later.

If brigades are (almost) always explicitly cleaned or destroyed, and 
buckets are always explicitly setaside, then what is the point of the 
overhead of registering auto-setaside functions for every pool bucket?

Conversely, is there a reasonable mechanism for avoiding the 
unnecessary setaside and allowing the removal of the requirement to 
explicitly setaside buckets? 

View raw message