Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-04-19 10:36:30

>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.
that is a shame. And I'm not sure exactly why does thread rely on it so
Would it be a big issue if the TSS cleanup didn't happen?
By the way, could I have (read) access to the version of [thread] you're
working on?

>>What do others think?
>I agree about the desirability of it (I am, in fact, using it that way
Glad we're on the same side ;)

>myself in some projects). Primarily for the reason I mentioned above,
>I'm not sure about the practicality of it in the long run.
Having [thread] as a DLL complicates life a lot.
As said before, I've ***abandoned*** (not used) [thread] for quite a
while, just because of this issue.
However, now I have some time to catch up on working on the
[smart_assert] library, which depends on [thread]. I really want to be
able to release [smart_assert] as a static library. Making it a dynamic
library will probably turn off many possible users of it - it would be
just one more DLL to worry about. Therefore, I made this patch.

>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?
I'm all for it! As long as we can have [thread] as a static library, I
really don't care how that happens.

Until the TSS issue is solved, would you please commit this patch to the
CVS? I think it's a good workaround - for the current [thread] version
in the CVS.
I'd really hate to abandon [thread] once again - just because of this issue.


Boost list run by bdawes at, gregod at, cpdaniel at, john at