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

John Maddock wrote:

I'm looking for second opinions on this bug report: https://svn.boost.org/trac/boost/ticket/5526#comment:1

[snip]

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?

I leak Singletons to avoid late referencing problems. The OS cleans up the memory, of course, so the only problem is memory checking tools that complain about the leak. Those can be configured to ignore the Singleton, and the docs can describe the behavior and rationale, so I consider that a quick, safe, and practical solution to the problem. If you want to avoid most memory leak complaints, you could create a second object that, upon destruction, asks the Singleton to release its dynamic resources. Then, if the Singleton is not actually used further, only the Singleton itself is leaked. OTOH, if there is a late use of the Singleton, it is still valid and can reacquire, and subsequently leak, whatever dynamic resources it then needs. (Then again, many memory checking tools look for leaks before statics are destroyed, in which case you are better off just letting the Singleton leak without extra steps.) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.