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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk