Joe Orton
Wed, 23 Jul 2008 06:13:25 -0700
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