Subject: [boost] [pool] pool-based allocators and order of destruction
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-05-15 06:04:33
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.