This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Critical ~__pool troubles (libstdc++/17937)
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: pcarlini at suse dot de, matz at suse dot de, libstdc++ at gcc dot gnu dot org
- Date: Mon, 11 Oct 2004 13:05:23 -0500
- Subject: Re: Critical ~__pool troubles (libstdc++/17937)
- Organization: Red Hat / Chicago
- References: <416AC4CB.5020902@suse.de><B37C28CC-1BAD-11D9-AFE2-000A95AA5E5E@apple.com>
Ugh. I'd thought about this ordering scenario this weekend, but hadn't
gotten around to testing it today. Looks like Paolo beat me to it!
>It's pretty much what you already said: nobody could think of a good
>reason to deallocate the pool explicitly, since it would only happen
>at the end of the program and at that point the OS would reclaim all
>the storage anyway. All you'll be doing is dirtying pages and making
>program exit slower, so why bother?
... all this was said in the mt_allocator.html doc additions (see
"Notes about deallocation").... I added this because I thought it could
be done, and was sick of getting user error reports about memory leaks.
I've seen at least two in the last six months.
However, it appears that it's not easily possible. Frankly, exploring in
detail other ways this can be done are probably not worth the effort or
overhead, considering _GLIBCXX_FORCE_NEW already works for debugging.
I'll revert this bit today.
-benjamin