Re: [boost] asio::demuxer at global scope dead-locks?

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