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 Wed, 23 Jul 2008 12:00:39 GMT
On Wed, Jul 23, 2008 at 08:34:17AM +0200, Mladen Turk wrote:
> If you create a socket for example in the constructor,
> socket registers it's own cleanup. This cleanup will be run
> *before* destructor meaning you are convicted to apr_socket_close,
> and you cannot cleanly close the socket via shutdown, or send
> some data upon destruction.

You could register a cleanup on the pool after creating the socket, and 
do whatever connection shutdown stuff in that cleanup, which would be 
guaranteed to happen before the socket is closed due to LIFO ordering.

But that does make the destructor a bit redundant - maybe the destructor 
callback is simply a bad fit for APR pools, full stop.  Given a reslist 
implementation which enforces a per-resource subpool what else would you 
need to do in a destructor that you couldn't do in cleanups?  The two 
examples in httpd using this API only destroy the subpool in the 
destructor anyway.

To be clear, I am not trying to argue that this problem can be easily 
fixed given the constraints of the current reslist API.  But the APR 
pools design has lasted essentially intact for over 10 years; I will 
continue to be concerned about any line of argument which goes:

1. we designed this API, shipped it, woo
2. oh dear, seems the API doesn't really work well with APR pools
3. hmmm, but we can't change the API now since it's shipped
4. so we need to change APR pools!

Obviously, however much you change APR pools, people will still be able 
to follow this line of argument.  So we need to differentiate between 
merely being at step (2) of that road to nowhere and finding a case for 
a generally useful enhancement to the pools API.

Regards, Joe

Mime
View raw message