[...] 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 much? 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. Best, John