From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-12 15:00:12
From: "William E. Kempf" <williamkempf_at_[hidden]>
> >
> > There are two very good arguments for (3) (exceptions from thread
function
> > objects cause std::terminate.) First, this is the most consistent
behavior
> > for the main thread. Second, having threads _not_ terminate the process
on
> > exceptions can (and reportedly does) lead to bugs that remain
undetected.
> >
> > But please note that these arguments have much less weight when applied
to
> > threads that return a value.
>
> Only when calculating the value was the sole purpose of the threads
> existance. Sorry, I know that sounds like a dismissal of what you're
> saying, and I don't intend it that way.
No, it's not a dismissal. It is a good summary. thread<R>, in my conceptual
model, is exactly a thread whose primary purpose is to calculate and return
a value. I believe that a significant portion of the "thread community" uses
such threads.
> It's just that my experience is
> that most threads do something more than just calculate a return value,
and
> this something more is an interaction with shared resources for which
> exceptions can lead to race conditions and dead locks if not properly
> handled.
Sorry. I don't follow the connection. It is true that exceptions when
handled incorrectly can cause race conditions, deadlocks, and resource
leaks; but I don't see how exception propagation (or lack thereof) affects
this problem.
> Of these, probably half or more could benefit from returning a
> value as well.
Perhaps, so I guess you are concerned about programmers (ab)using thread<R>
just for the return value, without taking into account how this affects
exceptions? The only real danger is using thread<R> but never checking the
return value with join(), and losing the exception.
General agreement with the rest of the post.