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
TSS...?
>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
>right?
>
>
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
smart_ptr's.
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
constructor/destructor calls.
>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.
<snip>
>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
windows.
(Not sure about gcc. Does anyone know?)
<snip>
>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.
Regards,
Roland