"John Torjo" <john.lists@torjo.com> wrote in message news:40839E26.5020403@torjo.com...
Dear boosters,
As far as I've heard a while back, the only reason [thread] library cannot be built as a static library was because of TSS.
I'm pretty sure this is correct.
That to me (and to others as I've seen) seems quite a show-stopper - in a lot of apps I don't use the [thread] lib just because of this. Most of my multi-threaded applications (around 95%) and as I know a lot of other multi-threaded apps. don't need TSS.
Even if they do, usually they don't need advanced clean-up code (reason for why [thread] was required to be a DLL). ***Most*** of the time, any allocated TSS objects can be let to leak resources (which they hardly have - mostly IMHO some small amount of allocated memory).
The above make me think that we really should enable [thread] to be a static library again ;). It should be documented in the docs that
All true enough, perhaps, but in the version of Boost.Thread in the thread_dev branch (which, as I've mentioned before, I'm slowly merging into the main branch as I have time), the thread class itself uses tss rather extensively, which complicates the issue quite a bit. the
static version of the [thread] runtime will leak TSS objects, and users can choose whether they will use [thread] as a DLL or as a runtime static lib.
What do others think?
I agree about the desirability of it (I am, in fact, using it that way myself in some projects). Primarily for the reason I mentioned above, I'm not sure about the practicality of it in the long run. I don't know if you remember seeing it, but what do you think about the approach Roland posted some time back that allowed a static library to act as if it were a dll?
As a side-note, allowing the [thread] lib to be a static lib is quite simple (please you gurus out there, correct me if I'm wrong). In fact, here's the patch.
[snipped long patch] Mike