perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [mp2 patch] APR::Bucket::alloc_ => APR::BucketAlloc
Date Tue, 28 Dec 2004 01:27:19 GMT
Stas Bekman <stas@stason.org> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message