From: Anthony Williams (anthwil_at_[hidden])
Date: 2002-08-27 05:34:42
Dan'l Miller writes:
> Although much debate occurred with many back-and-forth discussions, I
> never saw a clear & concise conclusion stating "Boost.threads shall do
> this" and "Boost.threads shall not do that" design decisions. Because
> those tumultuous threads have faded out
> , I assume that the topic has been discussed to the Boost community's
> satisfaction and that a complete set of conclusions was reached. I am
> interested in what the conclusions to the following topics were:
I am not entirely certain what Bill stated he was going to implement, but I'll
answer the questions anyway. Consequently, these answers reflect my opinions.
> q1) Is Boost.threads going to pursue any kind of conveyance of an
> exception thrown and not caught on a thread t back to the thread s which
> started t (i.e., conveyance as an exception-type instance, not expressed
> as an instance of a return type)?
Some form of conveyance, yes, but not necessarily back to the thread s that
started thread t.
> q2) If q1 is yes, in which circumstances? (e.g., in the case that s
> started t via a non-void template-parameter for the return-type concept)
In the circumstances that thread.join() is called for thread t. Some people
advocate that void-returning threads shouldn't propagate exceptions, but I'm
not sure I agree. In any case, I think all joinable threads should propagate
exceptions. If void-returning threads are not joinable, so be it.
> q3) If the criterion in q2 which precipitates conveyance of an uncaught
> exception on t is in fact a non-void template-parameter for the
> return-type concept, would t be joinable (as a chronologically-oriented
> boolean condition) if the return-type were
> void? (I suspect not, even though this occurs in existing MT practice.)
I hope not.
> q5) If in q3 a void return-typed t is not still joinable (i.e., t is a
> detached thread whose lifetime semantics are either 5a) run until
> end-of-process or 5b) run until t decides to end its own life), what is
> to happen to the nonjoinable t's uncaught
> exceptions?
Uncaught exceptions in non-joinable threads must terminate the process.
> q6) Is a void return-typed t the only way to create a detached thread
> which is not to be joined? If not, compare & contrast a void return-typed
> t semantics with a detached-the-other-way t<sub>1</sub>
Unspecified
> q7) For a detached t which by app-domain design is not to be joined, if t
> has an uncaught exception and if q1 is yes, does the detached-by-design t
> still convey the exception back to s?
Uncaught exceptions in non-joinable threads must terminate the process.
> q8) If q1 is yes, exactly which type is thrown in s (e.g., the same type
> as in t; all exception types thrown and not caught in t conflate to a
> single exception type in s)?
Unspecified, though we would hope that the re-thrown exception would match the
original as closely as possible --- maybe by providing a
thread_clone_exception() function.
> q9) If in q8 t's uncaught exception-type type is (re)thrown in s, exactly
> how would the exception be conveyed from t to s? E.g., if t's uncaught
> exception itself is the instance to be conveyed to s, then how would
> Boost.threads ensure that unwinding
> t's stack does not destroy t's exception instance.
t.join() would throw, rather than returning. Saving the exception instance is
unspecified, and depends on the conveyance mechanism.
> q10) If in q8 t's uncaught exception-type is (re)thrown in s but a new
> instance of t's uncaught exception-type is instantiated for s as part of
> the mechanism of how the interthread exception conveyance is
> accomplished, how does t convey that most-full
> y-derived type information to s? (Having merely a reference to
> ::std::exception in t does not tell anything about how to invoke a
> copy-ctor for the most-fully-derived type.)
Unspecified.
>
> q11) If q1 is yes, at which point would the interthread
> exception-conveyance from t ingress s? E.g., any old place; at the
> thread-join-with-t point; at a set of specially-picked standard C++
> library invocations.
At t.join()
> q12) If q1 is yes and q11 is the thread-join-with-t-point in s and if
> (re)throwing t's exception-type instance (uncopied) in s is the intended
> interthread exception-instance conveyance mechanism, how is t's
> exception-type instance preserved for (possi
> bly long) periods of time until s reaches the join point because t might
> have thrown before (and maybe quite a long time before) s reaches its
> join-point with t?
Unspecified.
> s13) If q1 is yes and q11 is the thread-join-with-t-point in s, then let
> us consider a still more troublesome case where s did not merely start a
> single thread t, but also n other threads too which are all to be joined
> back to s at a thread-join-with-
> T-point. In this case s started n+1 threads: T={t, t1, t2, ..., tn}. Let us
> consider the case where two or more threads in T experience trouble which
> is out of their league and thus two or more threads in T have uncaught
> exceptions which by q1 s would
> need to handle and by q11 would ingress s at the thread-join-with-T-point.
You can only join one thread at a time. If you join a thread with an uncaught
exception, the join operation throws. It is up to you to ensure that you
handle the exception and join other threads, if necessary.
> q16) If scenario s13 cannot occur, why not?
See above.
> q19) In reality why wouldn't q5's technique for handling an uncaught
> exception thrown in a nonjoinable t apply equally well to handling an
> uncaught exception thrown in a joinable t as well? (Why have two
> techniques instead of one?)
So you can get meaningful info from joinable threads, which have a
well-defined place at which to retrieve that information --- the call to
thread.join(). Non-joinable threads have no defined point at which to transfer
the information. If you want to do so, it is trivial to add a catch block to
the thread function, to store any relevant information before terminating the
thread, or whatever.
Anthony