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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-09-05 01:41:01

Christopher Kohlhoff wrote:

>--- Roland Schwarz <roland.schwarz_at_[hidden]> wrote:
>  
>
>>Why not simply use boost threads once function instead?
>>    
>>
>
>Does it address the issue of order of cleanup with respect to globals?
>
>  
>
This is indeed one of the hardest problems, specially when dealing with 
global objects.
E.g. there is a problem when the main thread is ending, but some other 
thread are
living even longer. I vaguely remeber some recommendation not using 
these globals
in MT at all. But I am not too sure. Also this sounds much to prohibitive.
Me for my part always ended with some kind of reference counting. This 
btw. is
what WSAStartup/Cleanup seemingly is doing inside. But I think you could 
simply
move the ref-counting into your code to be independant of WSAStartups 
peculiarities.
E.g. you could simply wrap up things into a shared_ptr.

>>I also discovered another issue:
>>The number of demuxers is implicitely limited by available TSS slots.
>>This also is an issue that long ago has been succesfully solved in
>>the threading library.
>>    
>>
>
>Yes, although the demuxer's use of tss is to keep track of whether the
>current thread is "in" the demuxer. The problem I had with the boost
>tss when I first investigated it a couple of years ago was that it
>seemed to involve storing an object in tss, when all I really wanted
>was a thread-specific boolean flag (and I had no need for cleanup).
>  
>
Not sure if I understand this correctly. You are using ::TLSFree don't you?
Besides how about
boost::thread_specific_ptr<bool> pbool;
pbool.reset(new bool);   ?
The thread_specific_ptr is doing almost what your class win_tss_bool is 
needing
to do anyways.

>>A final question is poping up:
>>Why not using the boost threading? Or is this planned for future?
>>    
>>
>
>It doesn't use boost threads internally so that it can keep the library
>header-file only, i.e. to avoid adding a dependency on any non-system
>DLLs or libraries.
>
I know this might seem a little ignorant, but could you please give me 
your rationale for
"header only" ?

> But if a future boost threads release was
>header-file-only for the most commonly used bits (threads, mutex,
>condition)... ;)
>  
>
There is currently a rewrite going on. I will try to drop this into our 
bag, but I am not
currently convinced that header only really is a win, but I would like 
you proving
me wrong. Good arguments could give raise to a header only 
implementation of basic
locking primitives too.

Regards,
Roland
(Speedsnail)