Hi Roland, --- 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. 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? 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.
Could it be that the "real" reason indeed also is to the header only argument?
That may be one of the reasons, but it's definitely not the only one.
Altough this currently is not a boost philosophy: Do you think prebuilt binaries could change this?
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.
But you force the user to longer compile times and the hassle of precompiled header manipulation for larger projects, don't you?
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. Cheers, Chris