From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-05 07:57:23
Christopher Kohlhoff schrieb:
>--- Roland Schwarz <roland.schwarz_at_[hidden]> wrote:
>>What I mean is this: You also need to take care to call TLSFree at
>>the correct time. So this makes no difference.
>Not quite. The TLSFree only needs to be done once for the tss object.
>But the newed bool must be freed for each thread, in each thread, when
>the thread exits. That is what I wanted to avoid.
Ok, I see. You could do away with the auto cleanup by specifying a
custom do nothing
handler, but that certainly is not what you would want to do, since you
would need ugly
casts from pointer to bool. I also remember that I was not too
comfortable with having
TSS only as pointers. But you need this, otherwise a complete
constructor call would be
incured at every thread startup. Perhaps it is a good idea to add
support for POD's into
>I just remembered that I also wanted to allow the threads that call
>demuxer::run to be created using whatever API the developer prefers, be
>it boost::thread, ACE, pthread_create or _beginthreadex. AFAIK to use
>boost's tss classes portably you also have to use boost::thread
>throughout your app to ensure the cleanup handlers get called. Is that
I always was a little unfomfortable with this too. As I see it there is
not really a need for this coupling.
Altough thread could benefit from TSS usage, but not necessarily the
other way round.
I would rather like to see the thread_specific_ptr belonging to the
Besides this the coupling does exist only in the boost headers and does
not force you
to use a certain threading API at all.
In the opposite one of the strenghts of boost::threads TSS
implementation is its independance
of the threading API despite the fact that it is able to do
>It makes me think it would be good to have a non-cleaning-up tss
>abstraction in boost. If there was one, asio could use it.
Perhaps this should be attempted for PODS.
>Perhaps, but it would be a lot of work to generate the builds for all
>the different supported combinations. It would also have to use
>autolinking wherever possible.
This already has been solved. The only thing missing is an installer for
(Not sure about gcc. Does anyone know?)
>Yes, perhaps, but my idea is that by the time the developer wants to
>use the library in larger projects, they are willing to commit time to
>use it more efficiently (such as using precompiled headers). It's the
>new user who's just evaluating it that needs the process to be as
>painless as possible.
Does the precompiled header thing also work for gcc on windows?
Besides this I always found it much more painful to get precompiled
headers working satisfactory. But this only my personal opinion.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk