Re: [boost] Boost.Threads static linking status report

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-08-06 05:49:44

On Thu, 5 Aug 2004 14:35:02 -0400 Michael Glassford <glassfordm_at_[hidden]> wrote:

> I've also used the opportunity to rewrite the rest of the Win32 tss
> cleanup code and update it to use the Boost copyright. In the process,
> I eliminated threadmon.cpp, threadmon.hpp, and pe_tls.cpp. They've
> been replaced by tss_hooks.cpp, tss_hooks.hpp, tss_pe.cpp, and
> tss_dll.cpp.

I just tried to run it on my machine. I observed the following:

1) Some CRLF issues. Some of the files (tss_pe.cpp) have strange CRLF
settings. There are single CR's and other stange CRLF sequences. I think
this was because of editing with MSVC. I can send you a cleaned version.
However what do you need? Unix (LF only) or DOS/WINDOWS (CRLF)?

2) The config.hpp got wrong:
The lines
#           #if defined(_DLL)
#           #else
#           #endif

should read:
#           if defined(_DLL)
#           else
#           endif

else a preprocessor error is emited.

3) I noticed that the call to 
//:         on_process_enter();
has been commented out.
I remeber you were saying it is not necessary. This might very well be true.
But in order to tackle the leak I even would suggest leaving it in and also
propose the following (extended) scheme for discussion.

on_process_init(); 
    getting called before the first constructor on 
    platforms where possible (and I strong believe there is a way on most)
    This could be used when available to do the global allocation of
    the tss_data struct.

on_process_enter(); 
     getting called after global ctors but just before 
     entering main or immediately on begin of main

on_process_exit();
    getting called just before global dtors are running

on_process_term();
    getting called after global dtors on platforms where
    possible. Ideally this should run when all threads have
    ended. This could also be the place to safely deallocate
   what is now causing a memory leak.

The on_process_init and on_process_term should be regarded optional
but improve memory consistency where possible. On platforms where
this is not possible it should revert to the current behaviour.
(Allocation on first usage.)

on_process_enter and on_process_exit should be mandatory.
Altough in the current implementation on_process_enter  seems not to be
really necessary, but I think it would be a benefit to have for other
library writers which will need to make sure to have an entry point
that is guaranted to run after the last ctor. (They could register their
handlers in a call to a global ctor e.g. )
Also they are easy to emulate on any system:
void main()
{
    on_process_enter();
...
    on_process_term();
}

What di you think?

Roland