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?
