Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
One thing I didn't take into an account:
my $ba = $r->connection->bucket_alloc;
now will be autodestroyed via DESTROY, which ensures yet another segfault,
since that $ba must not be destroyed by user code. Of course we may need the
same thing as we did with APR::Pool to distinguish native from custom
pools in DESTROY, but I tend to go on the lazy side and just add
s/DESTROY/destroy/.
Opinions?
+1 for s/DESTROY/destroy/. Allocators are really yet-another-
memory-management thingy from apr, and mapping pools to SV's was hard enough. The point we should make to mp2 users is
to stay the hell away from APR::BucketAlloc::create, and instead
look for some pre-existing bucket allocator like $c->bucket_alloc or
$bb->bucket_alloc.
Good point. I will do that.
So should APR::Brigade and APR::Bucket have DESTROY method added?
IMO: no for both. Buckets need to be managed by brigades, not SVs. Consider what would happen to a loop like
$bb->insert_tail(APR::Bucket->new($bb->bucket_alloc, $_)) for 1..10;
Similarly brigades should be dealt with by their registered
pool cleanups (or an explicit cleanup/destroy call). Note:
according to the docs, it is currently incorrect to muck with the brigade argument of ap_pass_brigade post-invocation, although AFAICT the current apache filters don't seem to exploit that fact yet. But they might someday, in which case an APR::Brigade::DESTROY method would likely cause more trouble than it'd be worth.
I've forgotted that this is already a known problem, I've tried to add APR::Brigade::DESTROY before and it was creating a problem with the brigades passed to filters.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
