Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at