This interesting to me. Sometime ago, I needed a singleton for an aspect of the serialization library. It looked like boost was going to have one but finally it didn't. I crafted one that seems very similar in concept to the one described by memory pool documentation. At the time I didn't realize that there was such a solution already in boost. It would seem that all these solutions would suffer from the same problem. It would also seem that the this (and some other "surprises" would be eliminated if one could assume that static global object would be destroyed in the reverse order of their construction. It seems that this always happens - but it's not guarenteed. Perhaps the thing to look at is thread_specific_ptr. Maybe it should get destroyed sooner if it's created later. Maybe a wrapper can be crafted for those late initialization - late destruction objects. Just an alternative thought. Robert Ramey John Maddock wrote:
I'm looking for second opinions on this bug report: https://svn.boost.org/trac/boost/ticket/5526#comment:1
The issue is this: if you use singleton_pool either directly or indirectly (via [fast_]pool_allocator), there is a potential order-of-destruction issue if you use it from within globally declared objects. I *think* it's OK, if the global object directly uses the singleton pool - or is it?
But, things get really nasty if it's used indirectly as in the bug report via a thread_specific_ptr - the latter gets destructed very late - much later than the pool which is used by the object it points to, so the result is a program crash on exit. In general though, anything that uses indirection and "late initialization, late destruction" will cause problems. I see a number of solutions:
* Document the limitation and leave it at that. * Make the singleton eternal and leak the pool's memory at program exit. * Use some kind of complex reference counting scheme so the pool is only destroyed when all it's memory has been released *and* main has exited. To be honest, I'm not thrilled by any of the above, but any opinions?
Thanks in advance, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost