Re: [boost] [thread] tss_cleanup_implemented issue

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-11-15 02:24:56

David Deakins wrote:
> In the most recent thread library changes from a day or so ago, the 
> set_tss_data function was added to win32/thread.cpp.  This function 
> calls tss_cleanup_implemented to force some support for TSS cleanup to 
> be present.

This is by intent.
>  Unfortunately, since set_tss_data is in the .cpp file 
> (rather than being an inline function in a .hpp file) this requires 
> tss_cleanup_implemented to always be present for WinThread versions of 
> the static library, regardless of whether or not TSS is actually used.

I agree, this is somewhat unfortunate. But the intent is that the 
application programmer always can define this function in her code,
if she knows that automatic tss_cleanup either is not needed, or taken
care of by th application itself. (By calling into at_thread_exit,....)

> Since WinCE does not currently have a nifty automated way to clean up 
> TSS in static builds, this means that there is always a link error when 
> the static library is used (even when no TSS data is allocated).  As an 
> alternative, could the call to tss_cleanup_implemented() be moved to the 
> thread_specific_ptr::reset() and thread_specific_ptr::release() 
> functions in win32/tss.hpp, so that the link error only shows up if some 
> TSS data is created?

I am afraid this is not possible since using thread implies linking to
tls.

> 
> Incidentally, while looking through this, I had a question about 
> src/tss_null.cpp.  Does this file actually accomplish anything at the 
> moment?  It appears that it is intended to patch in an empty version of 
> tss_cleanup_implemented() for WinThread builds when _MSC_VER is not 
> defined.  However, the #if block around the function definition includes 
> the clause (defined(BOOST_THREAD_BUILD_LIB) || 
> defined(BOOST_THREAD_TEST)).  As far as I can tell, this file is not 
> included in any static library build by thread/build/Jamfile.v2 and none 
> of the test files declare BOOST_THREAD_TEST.  So I'm not sure when this 
> function definition would actually come into play.  Just curious.

This file is currently used in the test suite. It allows for static 
linking even if automatic cleanup is not available. BUT: the tests are 
taking care of this, i.e they test for cleanup working or not.

For static linking you basically can take three approaches:

1) compiler/platform supports automatic cleanup: nothing to do.

2) ... does not support auto cleanup _and_

2a) you are sure you do not need tss: just define
     tss_cleanup_implemented
     (@anthony: is it possible for a thread application not to use tss?)

2b) you need tss:
     define tss_cleanup_implemented,
     make a call to on_process_enter() just on begin of main and a call
     to on_process_exit just before end of main.
     If you are launching threads _not_ by using the boost api:
     make a call to on_thread_exit() when the thread ends. If you are
     using the boost api to launch thread the last step can be omitted.

An additional note: The above should be better documented by me of
course. Also the above is not totally semantically equivalent with
the automatic cleanup in terms of when the respective functions are
really called. This needs some rethought.
But you should be able to call into the _on_exit function multiple times
safely. So at minimum one call sahll be present.

Btw.: Perhaps somebody noticed: I have added support for automatic
cleanup recently for the mingw compiler. Anyone knowing enough about
BCB so we can have this for Borland too?

Roland aka speedsnail