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

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-12 17:58:21

Since you now seem willing to allow this non-default option to be made
available, what kind of interface do you suppose it should have? Should it
be called asynchronous_call? advanced_thread?

In any case, it should just be a wrapper of the existing boost::thread, in
my opinion, because a non-templated implementation is necessary and there's
no reason we can't use the pre-existing thread object. Inheritance from
boost::thread is probably out of the question because it introduces the
possiblity that a user might mix threads with non-uniform policies. It is
also unclear how to handle a pool of threads that may throw exceptions on
join.

Is it at all possible to rename the current boost::thread class to
boost::basic_thread and supplant the template in its place? (Old users of
thread would have to change it to thread<> or just use basic_thread.) This
may deprecate the usage of the current boost::thread class because the same
functionality is acheived with thread<>.

----- Original Message -----
From: William E. Kempf
Newsgroups: gmane.comp.lib.boost.devel
Sent: Monday, 2002:August:12 5:53 PM
Subject: Re: Attempting resolution of Threads & Exceptions Issue

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>

> I am still left with the impression that I'm missing something. Could you
> illustrate this with an example? A program where moving to exception
> propagation causes exception-related problems.

It's not that exception propagation directly leads to exception-related
problems.  It's that it indirectly leads to them by lulling the users into a
misguided perception that exceptions are already handled appropriately.

For an example I'll once again go back to the classic bounded buffer.  Let's
imagine that I create a thread that's going to write out several items to
this buffer... a lot more than the buffer can handle with out another thread
reading the values out.  Let's also imagine that I create yet another thread
to read this values out and sum them up.  The result I'll return to the
caller when he join()s.  This is very similar to an async call, but between
the call invocation and the returning of the result there's important
inter-thread interactions going on.  With exception propagation I'm
concerned not only that the user may not call join() because he's not
interested in the result, only that the processing occurs, and thus could
never receive the exception.  No, I'm also concerned that if exception
propogation is the norm the niave user is lulled into thinking exception
handling is taken care of internally, and thus dead lock occurs when the
writing thread throws an exception while the reading thread is blocked
trying to read a value that will now never be added to the buffer.

On the one hand, I may be over emphasizing the importance of safety again,
but on the other hand I don't see any draw backs to making exception
propogation the non-default mode.  When safe to employ, it's trivial to do
so, when it's questionable or unsafe you have to at least consider the
consequences if you enable this.

Bill Kempf
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost