Important: in order to avoid unnecessary data copying the variable is stored in the bucket object. That means that if you modify $data after passing it to new() you will modify the data in the bucket as well. To avoid that pass to new() a copy which you won't modify.

It's important to know that certain bucket types (e.g. file bucket), may perform a split and insert extra buckets following the current one. Therefore never call $b->remove, before calling $b->read, or you may lose data.

If the bucket is not attached to any bucket brigade then this operation doesn't do anything.

When the bucket is removed, it's not not destroyed. Usually this is done in order to move the bucket to another bucket brigade. Or to copy the data way before destroying the bucket. If the bucket wasn't moved to another bucket brigade it must be destroyed.

Examples:

Assuming that $bb1 already exists and filled with buckets, move every odd bucket number to $bb2 and every even to $bb3:

However if your code doesn't know which bucket types it may need to setaside, you may want to check the return code and deal with any errors. For example one of the possible error codes is APR::Const::ENOTIMPL. As of this writing the pipe and socket buckets can't setaside(), in which case you may want to look at the ap_save_brigade() implementation.

Usually setaside is called by certain output filters, in order to buffer socket writes of smaller buckets into a single write. This method works on all bucket types (not only the mod_perl bucket type), but as explained in the exceptions section, not all bucket types implement this method.

When a mod_perl bucket is setaside, its data is detached from the original perl scalar and copied into a pool bucket. That allows downstream filters to deal with the data originally owned by a Perl interpreter, making it possible for that interpreter to go away and do other things, or be destroyed.

APR::Socket also provides auto-generated Perl interface for a few other methods which aren't tested at the moment and therefore their API is a subject to change. These methods will be finalized later as a need arises. If you want to rely on any of the following methods please contact the the mod_perl development mailing list so we can help each other take the steps necessary to shift the method to an officially supported API.