Re: [boost] Attempting resolution of Threads & Exceptions Issue

From: Dale Peakall (dale.peakall_at_[hidden])
Date: 2002-08-12 11:58:12

On Monday 12 August 2002 4:35 pm, you wrote:
> From: "Dale Peakall" <dale.peakall_at_[hidden]>
>
> > On Monday 12 August 2002 3:39 pm, you wrote:
> > > From: "William Kempf" <williamkempf_at_[hidden]>
> > >
> > > > This would, indeed, be a useful higher level construct.  I'd point
> > > > out that creating a thread on demand here would likely be a poor
> > > > choice.
> > >
> > > A good implementation can transparently use a thread pool to provide
> > > "instant" thread creation, _if_ creating a thread is a common 
> > > performance bottleneck based on users' reports.

Assuming you've got a thread-slot available - how does the user specify the 
appropriate number of slots if the system in entirely transparent.

> > Come on, it's going to entirely depend on an individual application as to
> > whether a thread-pool is appropriate.

> Perhaps we are using different definitions of "thread pool" and this is
> most likely my fault. Let me rephrase.
>
> An implementation can meet the specification as far as logical threads are
> concerned but, behind the scenes, not terminate physical threads
> immediately when logical threads terminate, in order to reuse them on the
> next logical thread creation.

OK, I've no problem with the library not completely destroying the underlying 
thread.

My misunderstanding - I use the term thread-pool for situations where you
have a group of worker threads all doing the same thing such as processing 
network events, the size of the pool generally resizes itself (between 
limits) based on load to continue giving reasonable response times to each 
individual client.

> > I do not believe that a *good implementation* should ever do this.  MT
> > programs are fidly little beasts and trying to do things like this
> > transparently in the library is just inviting disaster.  The program
> > writer needs to know what threads exist in the system and what they're 
> > doing so they can ensure that the interactions provide the intended 
> > behaviour, do not dead-lock, live-lock etc.
>
> The program writer needs to know what logical threads exist, because this
> is what is specified.