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

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
the
> exception when join is called.
>
> 2) as above, but with a policy object to allow the default to be
over-ridden
>
> 3) threads call terminate(), if you want other behaviour you provide a
wrapper
>
> 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
problem?

[...]

> This leaves us with 2 & 3 as viable solutions.
>
> Since both are viable, both solve the problems, and both have proponents
and
> 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
going
> to come down to opinion.  Here's mine:
>
> Have the default beviour be for threads to terminate on uncaught
exceptions.

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