Re[2]: [boost] Re: Windows MSVC thread exit handler for staticly linked Boost.Thread

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-08-04 03:27:47

On Wed, 4 Aug 2004 08:56:42 +0200 (W. Europe Daylight Time) Roland <roland.schwarz_at_[hidden]> wrote:

> BTW.: I am currently testing if there are any problems when linking
> the boost threads statically to a user DLL,

My findings so far:

Building a user DLL that is statically linked to boost surprisingly is disallowed.
I get the message:
#error: "Mixing a dll boost library with a static runtime is a really bad idea..."

Can anyone explain, please, why this should be bad?
This simply prohibits shrink wrapped user DLL code with embedded boost.
Are there any requirements of other part of boost that I am not aware?

Then: Of course linking with the dynamic version is possible, as was before.
Just one observation: The current implementation also suffers from the
wrong dtor order problem that Aaron metioned.
While in the case of threadmon this is not harmful thanks to a side effect
of the thread_specific_ptr dtor calling the delete's of any yet bound objects,
I consider this as somewhat 'unclean'.

In the DLL_PROCESS_DETACH the on_thread_exit is called for the main thread
                case DLL_PROCESS_DETACH:
                {
                    on_thread_exit(); // this does nothing 'really useful'
                    on_process_exit();
                    break;
                }
which is a no-op in our case at best.
If anyone ever will try to provide a user level atexitthread (similar to atexit)
it will fail badly, because of different semantics to atexit.

atexit will normally run before any global dtors. This is not so in our case,
because on_thread_exit is beeing called even after CRT deinitialization!
At this time I think no user level code should be called.

This could be cleaned up by a similar approach as in the static version
where atexit is scheduled after global ctor have finished.

Roland