From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-19 12:48:39
"John Torjo" <john.lists_at_[hidden]> wrote in message
> >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
> >into the main branch as I have time), the thread class itself uses
> >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
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]
> 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
I'm glad to have as many interested eyes as possible see the changes.
> 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,
I'm looking forward to it!
> which depends on [thread]. I really want to be
> able to release [smart_assert] as a static library. Making it a
> library will probably turn off many possible users of it - it would
> 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,
> really don't care how that happens.
> Until the TSS issue is solved, would you please commit this patch to
> CVS? I think it's a good workaround - for the current [thread]
> in the CVS.
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!
> I'd really hate to abandon [thread] once again - just because of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk