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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 16:02:32

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> 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.

The problem, as I state below, is that thread<R> is used for more than just
this limited purpose.  In some ways what we have is a disagreement in names
here.  You're happy with thread<R>, while I think it should be named
async_call<R>.  Of course, this really means seperate implementations for
numerous reasons, I think, but maybe that will help in understanding the
debate.

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

It leads to a false impression that the exception handling has been fully
encapsulated and there's little the user has to do but wrap join() in a
try/catch.  That's why I think the functionality may indeed be useful at
this library level, but only as a non-default option, to eliminate the
incorrect perception and force the programmer to think about what he's doing
(but at the same time making the exception passing uniform and easy).

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

Or in not handling exceptions appropriately in the areas where multiple
threads interact together!  That's the greater danger in my mind.

Bill Kempf