Critical ~__pool troubles (libstdc++/17937)
Benjamin Kosnik
bkoz@redhat.com
Mon Oct 11 18:05:00 GMT 2004
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
More information about the Libstdc++
mailing list