Graham Leggett wrote: > Branko Čibej wrote: > >> I think there may be some interest in this ... we've learned the hard >> way that pools as they stand today, while moderately nice for stateless >> server implementations, are less than moderately horrible for >> anything else. > > I strongly disagree. > > malloc and free are painful in the extreme, subpools give you all the > structure of object oriented programming, without the need to touch C++.
I'm quite mystified ... what does memory mangement have to do with OOP? Or specifically with C++? > Just replace malloc with apr_pool_create, and replace free with > apr_pool_destroy, and you are done. All right, I'll have to expand on that story it seems. But first -- using pool-create/destroy instead of malloc/free is nonsense, as the former are quite a bit more expensive in that case, and wouldn't have solved the problem I'm about to describe. But I digress. The problem I was refering to was about controlling pool lifetime in a long-lived process-wide cache where the controlling code happened to be in a DSO. (It's the DB_REGISTER hack in Subversion, details are in SVN archives). What happened was that the "global" pool that the cache was allocated from was destroyed /after/ the DSO was unloaded, leaving cleanup functions pointing to non-existent code. While eventually we managed to work around that problem, it would've been a lot easier if control over pool lifetimes were more explicit. I expect that with the new detached global pools in APR, that particular problem would never have arisen. The fact remains that control of pool lifetimes, whether in combination with DSO or long-lived memory structures, is a tricky problem not addressed by the current implementation. -- Brane
