Christopher Kohlhoff schrieb:
--- Roland Schwarz <roland.schwarz@chello.at> 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