Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk