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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-06 06:56:24

Roland wrote:
> 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. 

Darn, not that again.

> 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 think it must be the msvc 6 editor. I don't usually use it anymore, 
but did once or twice. For the most part I use msvc 7 editor, which 
seems to be ok (?) unless the file has inconsistent line endings to 
start with.

 > I can send you a cleaned version.
> However what do you need? Unix (LF only) or DOS/WINDOWS (CRLF)?

Thanks, but I've fixed the problems that I found.

> 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.

Fixed. Odd that I didn't see any error.

> 3) I noticed that the call to 
> //:         on_process_enter();
> has been commented out.

I commented this out while experimenting, and didn't notice it until 
after I had checked in the file. I didn't check in a fix right away 
because on_process_enter() doesn't currently do anything. It's fixed now.

> 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();
> }

Sounds OK.

Mike