Boost logo

Boost :

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-28 10:11:42

Roland wrote:
> On Wed, 28 Jul 2004 11:12:42 +0100 John Maddock <john_at_[hidden]> wrote:
>>>This is true, but the global object itself usually "lives" in an object,
>>which you "normally"
>>>need to free by means of the delete operator which in turn relies on
>>availability of
>>>the c-runtime.
>>The C runtime should be available and in a sane state for all thread
>>terminations except possibly the main thread right? So as long as we
>>possibly do something special for the main thread we're surely OK.
>>Certainly I've never seen your concerns in practice. What am I missing?
> It might not be of concern in practice, but as well it might.
> It is simply c-runtime implementation dependent.
> Some examples come to mind:
> 1) The MT-version of the library has some global variable such as e.g. the
> buffer for strbrk. Consequently you would not be allowed then to use this
> function in a destructor then. (Not a big deal, but....)
> 2) The MT-version of the c-runtime (at least MSVC) does some floating
> point init/deinit. How's about using floating point in a destructor?
> 3) Think of a debugging library that tracks memory allocation with respect
> to threads. You would need some means to access the "living" thread. How's
> about this?
> I simply think it is never good using something after it has gone, without the
> explicit notion that this is ok. And since the standard does not deal with threads
> explicitly one should be very careful I think. Some very nasty and hard to
> detect bugs might be the consequence.

I'm not sure if it's documented anywhere (if not, it would be bad to
rely on it, of course), but the behavior I have observed is that if my
dll depends on another dll, Windows calls the other dll's process-attach
and thread-attach before mine and its thread-detach and process-detach
after mine. If this is documented to be the case, doesn't that solve at
least most of this problem?


Boost list run by bdawes at, gregod at, cpdaniel at, john at