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