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
1 additional thread per thread probably wouldn't make much difference. A naive implementation of a socket server that allocated 1 thread
"Malcolm Noyes" <boost@alchemise.com> wrote in message news:ntqjc012df7c2tcrt1offg51b2gp9sj1t0@4ax.com... then 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).
Also, I'm still not convinced that tss cleanup on *thread* exit is
Thanks for doing so much of my work for me--it will get done a lot faster that way. 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