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

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-08-04 08:33:18

On Wed, 04 Aug 2004 08:51:35 -0400 Michael Glassford <glassfordm_at_[hidden]> wrote:

> Thanks, that did turn out to be the problem. It works fine, now, which 
> is really good news.

Fine.

I am currently trying to unify both versions (7 and 6). This also seems to be necessary,
because Aarons code while paving the way yet has some minor problems (also on vc7):

While it is very interesting, that it is not mainCRTStartup which is the very first function
of the executable that receives control, it may be problematic in our case.

I disbelieve that the threading library is prepared to be the very first in town (not
even the EXE's entry point has been called yet!) and so I think it is much safer to 
initalize everything after the runtime system is up, but before main.

BTW.: I found the following in the documentation of the CRT:
;***
;defsects.inc - defines sections.
;
;   Copyright (c) 1989-1997, Microsoft Corporation.  All rights reserved.
;
;Purpose:
;   This file defines sections for the C and C++ libs.
;
;   NOTE:  As needed, special "CRT" sections can be added into the existing
;   init/term tables.  These will be for our use only -- users who put
;   stuff in here do so at their own risk.
;
;******************************************************************************

and then
;  XIA  Begin C Initializer Sections
;  XIC   Microsoft Reserved
;  XIU   User
;  XIZ  End C Initializer Sections

and so on.
I believe using the XnU sections may be regarded rather safe usage then.

Also I would like to propose the following:

Instead of the threadmon.cpp including the pe_tls.ipp file we should simply leave
the static part empty.
Then we put into the library a pe_tls.c file which exports
void on_process_enter(void);
void on_process_exit(void);
void on_thread_exit(void);
and
void tss_cleanup_implemented(void) ;

when the user code now provides its own implementation of these function
she overrides the boost.thread library versions.
This not only will increase compatibility with the current status but also
provides a default implementation.

What do you think about this?
I will try this out and post something when ready.
Also I will be a little more conservative about the meaning of _tls_used
as Aaron pointed out. It is not really necessary to acces any of its fields
directly.

BTW.: did you ever consider providing the user level function atthreadexit
that seems to be having been planned by W.Kempf?

Roland