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.
[...]
> 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.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
