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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 14:03:23

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "Dale Peakall" <dale.peakall_at_[hidden]>
> > On Monday 12 August 2002 5:03 pm, you wrote:
> > > From: "Dale Peakall" <dale.peakall_at_[hidden]>
> > >
> > > > > > 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>.
> > >
> > > Most definitely, since thread<R> where R != void produces an interface
> > > where join() returns a value, and this is not covered by (3).
> >
> > 3 can still return a value.
>
> Yes, I have probably misunderstood what you mean by (3).
>
> 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.  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.  Of these, probably half or more could benefit from returning a
value as well.  So of the ones that return values you're probably (roughly
speaking, and obviously varies from app to app) at about a 50/50 split on
the viability of passing exceptions as being a sound policy.

> But we digress. My point was that Boost.Threads should provide significant
> added value over pthreads.

And I hope it does, and I'm working on covering the areas where pthreads
currently has more utility then Boost.Threads.  I realize your point was
specific to this one design issue and not a generalization, but I still felt
I had to defend myself from the generalization as well.

> I said that we shouldn't _overuse_ the "low level library" argument.
Library
> design is a delicate balance; deciding what should be included and what is
> to be left out is difficult (probably the most difficult part.)

Yes, but "low level" or not, the design should still be minimalist.  Other
libraries can extend this, which keeps the overhead (both programmatic and
conceptual) to a minimum.  You apply the same reasoning with shared_ptr, for
instance.

I'm not saying that the "minimalist" argument is the final say here, just
that it's a valid thing to add to the mix of considerations.

> It is best to look at things from users' perspective. True, feature X is
> easily built on top of the core subset Y. But if a significant group of
> users will need to reinvent X because it is needed to solve their
problems,
> then it is our responsibility as library designers to include X.

But not necessarily in the same library.  As I've pointed out, threads are
but one way to implement async calls and the end user would be much better
served with a library that was more generic and applicable in these other
domains as well.

> Examples of X?
>
> * a thread that returns a value (including exceptional returns);
> * a thread-safe join() where a second join() is a no-op;
> * a way to obtain a full-featured "handle" to the current thread;
> * a way to put threads in standard library containers;
> * a thread identifier usable as a std::map key;
> * a way to solve the initialization order problem in the presence of
> threads.

I'm working on all of the above(*), though I'm still concerned about
"exceptional returns".  I'm not flatly refusing to add this functionality,
but if I do I'm likely to opt to make it the non-default behavior for the
reasons I've repeated numerous times in this thread.  Even for threads that
return values.

Bill Kempf

* Yes, I truly am working on solutions to all of the problems in your list.
You can be assured I will have something implemented for every one of these
in the next revision when I ask for a review.