[boost] [pool] pool-based allocators and order of destruction

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.