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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 10:48:24

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> 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.
> >
> > Come on, it's going to entirely depend on an individual application as
to
> > whether a thread-pool is appropriate.

Yep, and that's what I was pointing out when I said "creating a thread on
demand here would _likely_ be a poor choice".  To be truly useful this high
level library would need to provide me with the ability to choose *how* the
call was made asynchronous.

> Perhaps we are using different definitions of "thread pool" and this is
most
> likely my fault. Let me rephrase.

What's said below makes me think that's probably true.

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

That's the concept I know of as a "thread pool", and is what is in the
current development branch by the name of boost::thread_pool.

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

Precisely.  And the thread_pool concept doesn't cause issues in this area.
Or are Mr. Dimov and I missing something?

Bill Kempf