From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-12 09:35:49
From: "Dale Peakall" <dale.peakall_at_[hidden]>
> Proposed Solutions:
> 1) thread<void> threads call terminate(), thread<XXX> threads propogate
> exception when join is called.
> 2) as above, but with a policy object to allow the default to be
> 3) threads call terminate(), if you want other behaviour you provide a
> 4) threads call thread_terminate() which can do the right thing
> 1 is just a sub-set of 2 and I haven't seen any objections to the concept
> that adding a policy (if it defaults) is inherently a problem.
Why not add seven defaulted policies, then, when it isn't inherently a
> This leaves us with 2 & 3 as viable solutions.
> Since both are viable, both solve the problems, and both have proponents
> opponents, we're left in a sticky situation. Concensus is not going to be
> achieved by arguing the technical merits of the case. In the end, it's
> to come down to opinion. Here's mine:
> Have the default beviour be for threads to terminate on uncaught
This is common between 1/2 & 3. What 3 calls a "thread" 1 calls
"thread<void>" and the behavior is as specified above.
> I base this simply on my opinion that a thread() is different from an
> async-call and that the thread library has tried to remain a low-level
> library that provides us the tools for writing higher-level abstractions
> (which is why it doesn't provide monitor classes etc).
I think that the "low level library that allows users to do the work"
argument must not be overused. If I want a low-level library, I will use
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk