"John Torjo" <john.lists@torjo.com> wrote in message news:4083F1FE.6020409@torjo.com...
[...] 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?
The reasons are two-fold: 1) The thread class becomes a handle class that holds a reference-counted pointer to a thread_data class. When a thread class is created, it gets access to the thread_data class for the thread using TLS. 2) As you might guess from the name of the thread_data class, there is other information associated with each thread; for instance, a thread id, a flag indicated whether the thread has been cancelled (yes, there is an exception-based implementation of thread cancellation), etc.
Would it be a big issue if the TSS cleanup didn't happen?
Given the above-mentioned changes, it probably is. The TSS cleanup is what calls the thread_data destructor, which is what performs the thread cleanup (CloseHandle for Win32, pthread_detach for pthreads).
By the way, could I have (read) access to the version of [thread] you're working on?
Everything is on the thread_dev branch of the Boost cvs. Most of the work was done by Bill Kempf, but he didn't completely finish it; I'm primarily reviewing the code, changing or adding what seems necessary to me to make it complete, then merging it into the main branch after asking for comments on this list. I haven't done anything with the thread class yet, but it makes sense to me why the changes were made, including the dependence on tss. For access, either do a cvs update of Boost's ...\libs\thread and ...\boost\thread directories using anonymous access and the the "-r thread_dev" switch or see http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/thread/src/thread.cpp... and http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/thread.hpp?on.... I'm glad to have as many interested eyes as possible see the changes. [snip]
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
I'm looking forward to it! 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
I'll take a look at it as soon as I can; unfortunately, probably not today. If you don't hear back from me soon about it, please remind me! this issue.
Best, John
Thanks, Mike