This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: mt_allocator: static DE-initialization order fiasco?
- From: Carlo Wood <carlo at alinoe dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Mon, 11 Oct 2004 01:19:05 +0200
- Subject: Re: mt_allocator: static DE-initialization order fiasco?
- References: <20041010162821.GA8496@alinoe.com> <41696BEF.1010903@suse.de>
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>