Re: [boost] Everyone: Thoughts on threads & exceptions

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

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, August 05, 2002 2:57 PM
Subject: [boost] Everyone: Thoughts on threads & exceptions

> Any reasonably designed "MT" paradigm (here I assume your lazy hands mean
> "multi-threading", or maybe it's just the nature of your isolating /
> self-promoting profession)

Careful.  The tone is turning bad here.  Yes, MT stands for multi-threading.

> can require a call to thread.check_exception ()
> somewhere, if not a call to join () (which is usually a good idea to do).

Only by convention, not by any means enforcable in the language.  But let's
say that we can live with just documenting that the poll must take place.
Now the trick becomes, "when"?  Poll in the wrong place and you still wind
up with (at least the potential for) code that accesses invalid data because
of an exception that wasn't caught in some other thread.

Exceptions are, by design, meant to either be caught or to propogate up the
calling stack, but you're suggesting something that's neither of these.
Will it work in certain circumstances.  You betcha... and that's why it's
supported in the current design.  But it's not a good idea in general, and
so won't be the default behavior for all of the reasons I've enumerated.

> Why not consider other alternatives instead of dismissing all forms of
> multi-threaded exceptions. Such as: a timeout that eventually calls
> terminate () if an exception is observed in time. I'm sure other ideas can
> be conceived as well...

I've already considered alternatives, and will consider any that are brought
to my attention that I've not already considered.  In this case your
suggestion was considered and rejected some time ago, and nothing new has
been brought up to change the reasoning for rejection.

> In any event, more functionality, and user configurability can allow it to
> work in almost every situation. boost's multi-threading paradigm show not
> preclude certain usage. As I already mentioned, a call to terminate () is
> trivially enabled.

The design doesn't prevent you from trivially eating the exception and
reporting it's occurance in a polling situation today.  It doesn't require
your "advanced_thread", it only requires a function object wrapper/adapter,
which has the added benefit of being usable in other circumstances, such as
with the upcoming boost::thread_pool or in boost::signal, etc.

In any event, the default behavior should be predictable and in accordance
with existing semantics, which means that the default should be to call
terminate().

Bill Kempf