perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Förtsch <>
Subject Exceptions in APR::Pool cleanups
Date Sun, 18 Mar 2012 13:41:59 GMT
On Saturday, 17 March 2012 11:03:32 Torsten Förtsch wrote:
> Further, I'd like to implement tests for C<die $string> and 
> C<die $reference> in a pool cleanup

This is a request for comment. So please comment!

Should we really allow pool cleanups to throw exceptions?

Assuming I have a pool with 2 registered cleanups. One dies. Should the other 
be called if the first one dies?

If yes, what should the value of $@ be if the second one also dies? If the 
second one does not die should $@ be cleared?

After a bit odf thinking about it I tend to forbid pool cleanups (and 
PerlCleanupHandlers) to die. If they do we can:

1) completely ignore the exception

2) stringify it and write it to STDERR

3) gather it in a special hash, e.g. @APR::Pool::cleanup_exceptions

Anyway, the current code in trunk is wrong. No matter if we rethrow the 
exception as is or a stringified version of it, we must not leave 
mpxs_cleanup_run() via longjmp() due to the way apr_pool_destroy() is 

APR_DECLARE(void) apr_pool_destroy(apr_pool_t *pool)
    /* Run cleanups */


    /* Remove the pool from the parents child list */
    if (pool->parent) {
        if ((*pool->ref = pool->sibling) != NULL)
            pool->sibling->ref = pool->ref;

At first, all cleanups are run. Only then the pool being destroyed is 
disconnected from it parent. So, if we leave one of the cleanups via non-local 
goto we get partly destroyed pool still connected to its parent. Now, when the 
parent is destroyed it will destroy the partly destroyed one again.

Torsten Förtsch

Need professional modperl support? Hire me! (

Like fantasy?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message