apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Changing the order of cleanup for some core objects
Date Mon, 21 Jul 2008 11:01:44 GMT
On Mon, Jul 21, 2008 at 12:38:18PM +0200, Mladen Turk wrote:
> Joe Orton wrote:
>> 2) No APR function is defined to be async-signal-safe, calling  
>> apr_pool_destroy(P) from a signal handler is liable to crash and burn  
>> regardless of how you change the cleanup ordering.
>>
>
> Well, hitting CTRL+C shouldn't cause the core :)
> I probably wrongly explained the issue. Pool detachment from the parent
> is guarded by mutex (I'm here referring to the threaded usage), so
> pool can be destroyed asynchronously.
>
> Of course the client code must provide the needed synchronization,
> but even with that there is a problem with reverse execution order
> of the callbacks; childs are destroyed before or after the cleanup
> depending on the initiator. For sockets as an example with pool_destroy
> or cleanup case the socket is always hard closed (by invoking its
> pool cleanup callback)

I still don't understand the problem at all.  Can you give an example of 
something which cannot be done today because of the current design of 
APR pools?

In the model where you have S allocated out of P, let's presume we also 
have a subpool Q.

If for some reason specific to the design of your application, you need 
S to be closed before the destruction of Q, you can register a cleanup 
against Q which does calls apr_socket_close(S).  That will give defined 
behaviour.

The pre_cleanup stuff seems to be entirely redundant in this regard.  I 
don't understand the motivation for it in the first place, to be honest.

joe

Mime
View raw message