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

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
>> 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