Tonko Juricic wrote:

Michael Glassford wrote:

...

The upcoming 1.32.0 has some support for building as a static library (i.e. you can build it that way, but you must call functions at appropriate times--

BTW, I should have said "on Win32 you must call functions..." here.

...

not an easy thing to do--to prevent the memory leaks if you use thread_specific_ptr).

...

Hopefully the next release after 1.32.0 will do cleanup for you automatically.

Mike,

I'm still reading group archives to catch up with the past issues so the following may be a dumb question:

Assuming that motivation is to provide cross-platform support for thread_specific_ptr (that is my current understanding), is it worthy of complications with thread exit cleanup?

I tend to think that only people familiar with threading issues would use thread_specific_ptr, therefore 'generic' thread code should not be responsible for tss cleanup.

If you don't want complications, use the dll version of Boost.Threads for Win32. You can use either the dynamically linked or statically linked version on other platforms. The reason I included a partially working (on Win32) version of a statically linked Boost.Threads library is that some people *really* want static linking; it's one of the most frequent Boost.Threads requests. This version is for developers who: a) Know that they don't really need tss cleanup, so they don't need to call the cleanup functions (not recommended unless you're really sure you know what you're doing); b) Are statically linking Boost.Threads into their own dll, where they can detect thread exit in their own dllmain function and can call the appropriate cleanup functions; c) Have other application-specific ways to detect thread exit (e.g., they create their own threads using a class other than boost::thread and can call the appropriate cleanup functions when the thread function returns). d) Want to experiment with ways of adding full tss-cleanup support for a future version of the statically linked Win32 Boost.Threads. Mike