Boost logo

Boost :

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

"Malcolm Noyes" <boost_at_[hidden]> wrote in message
> >> The simplicity of this [one thread per thread]
> >> design might be preferable to the limitation/complexity imposed
> >> 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
> 1 additional thread per thread probably wouldn't make much
> A naive implementation of a socket server that allocated 1 thread
> 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
> >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
> 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 .


Boost list run by bdawes at, gregod at, cpdaniel at, john at