[boost] Re: Re: [thread] again ;)

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-04-19 12:48:39

"John Torjo" <john.lists_at_[hidden]> wrote in message
news:4083F1FE.6020409_at_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?only_with_tag=thread_dev
and
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/thread.hpp?only_with_tag=thread_dev.

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,

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
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'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
this issue.
>
> Best,
> John

Thanks,

Mike