From: Malcolm Noyes (boost_at_[hidden])
Date: 2004-06-11 12:44:54
>> The simplicity of this [one thread per thread]
>> design might be preferable to the limitation/complexity imposed by
>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 . .
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk