mt_allocator: static DE-initialization order fiasco?

[Carlo Wood]

On Sun, Oct 10, 2004 at 07:05:51PM +0200, Paolo Carlini wrote:
> To be sure: are you using the latest src/mt_allocator.cc, version 1.4??

RCS file: /cvs/gcc/gcc/libstdc++-v3/src/mt_allocator.cc,v
Working file: mt_allocator.cc
head: 1.4
branch:

> In any case, a small testcase would help...

I cannot create a small test case because because I don't
know how to make a shared (C++) library be destroyed after
libstdc++.  It makes sense to assume that is not
possible at all (although I always assumed that no order
is garanteed in which libraries will be deinitialized).

In that case, the only way one can write a test case
would be by explicitely creating a memory pool oneself.
Before I put time into that I'd prefer it if you first
answer my question whether or not __mt_alloc is to
be considered 'external interface' that a user may use
or not.  If not, then it may only be used by libstdc++;
and because that doesn't have any static/global STL
containers by itself and - as I assume - will always be
deinitialized last - there wouldn't be a potential problem.

The reason I ran into this "deinitialization order fiasco"
myself is because I DO use __gnu_cxx::__mt_alloc in my
library (I need separate memory pools for certain containers).

-- 
Carlo Wood <carlo@alinoe.com>