[boost] Re: [thread] again ;)

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-19 06:19:04

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:40839E26.5020403_at_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).

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 above make me think that we really should enable [thread] to be
a
> static library again ;). It should be documented in the docs that
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