[boost] Threads & Exceptions...

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-12 14:33:53

It seems like everyone has lost the original direction of the original
conversation. I like to wax philosophically just as much as the next girl or
guy, but arguing over interpretation of the standard is not very useful. It
is clear that we are working beyond the bounds of the standard, we will all
have to except that some rules will have to be bent, or just do not apply.
(Some of us probably feel like all of the work that goes into threading will
get proposed to the standard one day, but C++ with multiple entry-points is
likely too different for some simple tuning of the existing standard, and
will likely require a proposal to an entirely different language.)

What are the issues that plague us today that aren't subjective? When it
comes to the usage of the exception policies, I don't see much room for a
subjective argument. The policies allow the instantiate of the template to
define the rules of how it will behave. Someone could propose an argument
that exceptions on a call to join () are dangerous if it is unknown to the
user of join that it will throw. However, typesafety is on our side with
respect to the policy of a given thread so it would be unlikely that a user
wouldn't know the behavior of a thread (even if it were created by a boost
dependent library).

It's clear to me that if one needs the return value of a thread, they will
certainly call join. If the thread has no return type, the default behavior
is to terminate on exceptions, which everyone agrees on. We may just have to
blame the fact that an exception can be stored but never actually thrown (by
failing to call join ()) as just the nature of the framework we are stuck
in. There are existing alternatives which fall under the not-so-nice
category, like having the exception policy call terminate () on destruction,
which in a long-life system, could be on a scale of months before it
actually happened--other creative solutions welcome... of course, these
solutions can be invented by the end-user as well.

It is not clear to me how 'polling for exceptions' introduces race
conditions, or how/why anyone would be 'polling for exceptions'. The
exceptions are checked for the user after the call to the implementation's
join (), so that is a non-issue. If there is a possibility to by-pass join
and check for exceptions directly in the public interface, I can't see how
this would possibly introduce any 'race-condition' either in a well designed
thread class--certainly the designers of a thread class understand how to
make a method that accesses and attribute thread-safe. In any case, it
doesn't make sense to poll for exceptions because they do not exist until a
call to join would pass through successfully anyway.

I don't think anyone can argue against the policies themselves, which allow
the end user to mutate the behavior of the thread to do whatever they
need--certainly as designers, we can't preclude unforeseeable usage. I can
see room for argument about which policies should be promoted by boost
itself, but again, everyone can see by our conversations alone that a
terminating policy and an exception throwing policy are in fact useful and
needed.

I don't know of any part of boost that actually depends on Boost.Threads and
creates them for the user. If that were the case, I can understand how there
might be arguments as to which policy this hypothetical Boost.XXX us, but
then again, I think we would all have to settle on letting the end user
determine the policy just as with the threads, because boost is a
framework -- not a client -- as such it does not need to make any decisions
in the realm of the end user.