From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-16 23:13:57
Edward Diener wrote:
> Michael Glassford wrote:
>>Michael Glassford wrote:
>>>I've made some changes to the Boost.Threads static linking support on
>>>Win32. Previously I had added back support for static linking, but
>>>without thread-specific storage classes. Now I've added the
>>>thread-specific storage classes back in, and exposed two functions
>>>that need to be called at the appropriate time:
>>>The function on_thread_exit() should be called when a thread exists,
>>>*in the context of the exiting thread*. The function
>>>should be called when the process exit. If these functions are not
>>>called at the appropriate time, leaks may occur. If you know you
>>>don't need tss cleanup, of course you can just omit to call these
>>>In addition, Boost.Threads static library on Win32 requires the user
>>>of the library to define a function called
>>>tss_cleanup_implemented(); if it is not defined, a link error
>>>results. The only purpose of this function is as a "link-time
>>>assertion": the linker error stating that the
>>>function is missing warns the the user of the necessity of calling
>>>the cleanup functions. In addition, if Boost.Threads later
>>>implements tss cleanup in the static library, the linker's duplicate
>>>should warn the user that their custom implementation is no longer
>>Replying to myself: I forgot to mention: it's easy enough to make
>>threads created by Boost.Threads call on_thread_exit() after the
>>thread function exits.
> Please explain how if there is an easy method.
I mean it's easy enough for me to do it in the Boost.Threads code; I
meant to ask if anyone thought I should do so, or if there were
drawbacks to having the library do it. I guess I forgot to ask.
>>Does anyone see any drawbacks to doing this?
> The only drawback is the typical one of a thread being killed before it can
And the drawback that it only deals with threads created by
Boost.Threads; other threads will leak any resources contained in tss.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk