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?
Mike