[boost] Re: Thread lib (good reason for static)

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-11 12:59:39

"Malcolm Noyes" <boost_at_[hidden]> wrote in message
news:ntqjc012df7c2tcrt1offg51b2gp9sj1t0_at_4ax.com...
> >>  The simplicity of this [one thread per thread]
> >> design might be preferable to the limitation/complexity imposed
by
> >> WFMO.
> >
> >I don't agree, but having different opinions is definitely allowed
:-)
>
> I seem to recall being told once to avoid premature optimisation ;-)
> Unless a developer is in the habit of creating threads frequently
then
> 1 additional thread per thread probably wouldn't make much
difference.
> A naive implementation of a socket server that allocated 1 thread
per
> connection probably wouldn't perform well for example. Needs to be
> tested to see what the limits are, I think.
>
> >I believe all of the above suggestions (including the WFMO + event
> >variation) would render it impossible to use boost's tss
functionality
> >outside threads created using Boost.Thread.
>
> Not sure I agree.  I have test cases running now that work with
> non-boost threads and seem pretty simple to use.  I have more tests
> that I want to implement, including MFC UI threads (and I see no
> reason why it shouldn't work).

Thanks for doing so much of my work for me--it will get done a lot
faster that way.

> Also, I'm still not convinced that tss cleanup on *thread* exit is
the
> best option; for a thread pool I still think that I'd want automatic
> cleanup on *functor* exit (for the same reason that exception
> propogation should probably happen on functor exit).

It would probably be easy enough to make the functor trigger the tss
cleanup, or perhaps to make the thread pool wrap the functor with a
functor wrapper that triggers tss cleanup when it exits.

> Perhaps an
> implementation that works with QueueUserWorkItem wouldn't go amiss .
.

Mike