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

From: Dale Peakall (dale.peakall_at_[hidden])
Date: 2002-08-12 10:36:04

On Monday 12 August 2002 3:35 pm, you wrote:
> 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?

I'm sorry, I don't really get your point here.  I've not seen any suggestions 
for more than one policy.

My analysis of follow-ups to the option proposed by Victor Wagner that we use 
a policy to determine whether or not exceptions are propogated, was that you 
weren't exactly keen, but felt that a compromise would be to have the policy 
default based on the return type.  If I'm wrong, please clarify.

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

Only for thread<void>.

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

You appreciate that using pthreads denies you a large number of advantages 
that can be derived from using boost.threads: Cross-platform 
interoperability, exception safety, a C++ style interface etc.

Boost.Threads is a low-level library, but it's a low-level *C++* library, 
that solves a large number of *C++* problems.

        - Dale.