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