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
> > > > 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
> > > bottleneck based on users' reports.
> > Come on, it's going to entirely depend on an individual application as
> > 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
> 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
> 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
> > needs to know what threads exist in the system and what they're doing so
> > 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
> what is specified.
Precisely. And the thread_pool concept doesn't cause issues in this area.
Or are Mr. Dimov and I missing something?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk