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

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-09-05 06:34:31

Hi Roland,

--- 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.

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