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

Subject: Re: [boost] [pool] pool-based allocators and order of destruction
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-05-15 11:19:02

> 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.

Actually I think it should be guarenteed, but I can't find the relevant text 
at present :-(

> 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.

To clarify the issue is:

* Global object is constructed "early".
* Main starts.
* Global object first references singleton_pool at this point - so 
singleton_pool gets constructed "late".
* main exits.
* singleton pool is cleaned up first (because it was the last to be 
constructed).
* Global object is cleaned up.... oops, it's still referencing the pool.

So it's the sort of issue that only a garbage collector can solve - albeit 
we're looking at coded reference-counted collectors.

Cheers, John.