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

Subject: Re: [boost] [pool] pool-based allocators and order of destruction
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-05-15 11:39:13

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