Boost logo

Boost :

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
> > objects cause std::terminate.) First, this is the most consistent
> > for the main thread. Second, having threads _not_ terminate the process
> > exceptions can (and reportedly does) lead to bugs that remain
> >
> > But please note that these arguments have much less weight when applied
> > 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,
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at