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). 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). Perhaps an implementation that works with QueueUserWorkItem wouldn't go amiss . . . Malcolm Malcolm Noyes