well, maybe. if we go destroying major pools (request, server) before it's time that could be bad. and if $r->pool is paired to an APR::Pool object, and $r goes out of scope, that would call APR::Pool::DESTROY, right?
OK, I see what kind of worms can it opens. r->pool is not an SV*, so it won't get destroyed by perl's DESTROY but by httpd internals at the end of the request. However if you do: my $r = $r->pool anywhere in the code, its reference count will be one, and it'll be DESTROYED at the end of the scope, messing things up.
So we want DESTROY to work for privately created pools, but not for internal pools, that gets tricky. One solution is to have APR::Pool::new() do something special to an SV that it creates, e.g. set some flag or attach magic. When DESTROY is called it should do its work only on those SVs marked as DESTROY-able.
cool. I'll try and do something like that.
Do you think it should be here, as there is no apr_pool_DESTROY function. I'd think that it should be in modperl_functions, but may be putting all related mappings together is better.
After all this is the same:
xs/maps/apr_functions.map: apr_uuid_DESTROY
it doesn't matter to me. I was just trying to get something working first - we can shuffle and tweak the implementation after it is doing what we want.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
