[cpp-threads] Issue 1369 --- thread safety of std::rethrow_exception

[N.M. Maclaren]

On Nov 15 2010, Anthony Williams wrote:
>On 13/11/10 15:01, Detlef Vollmann wrote:
>
>> The
>> interesting point here is that for this you really want one single
>> exception object, and not multiple copies floating around.
>
>Would you really expect that to work across multiple threads?
>
>> I think if you really want a copy, you should make it yourself (using
>> some clone() function).
>
>Please, no. If we do that then pretty much every use of 
>shared_future::get() where the exception is allowed to propagate must 
>somehow clone the exception (the type of which we don't know) in order 
>to avoid introducing data races to the caller.

To reiterate what Hans said "I'm a bit concerned that we're talking about
a bunch of different things here"!  I think that there are two uses of
the concept "exception" being used.

The first one refers to a handle to the actual event; that kind of object
is NOT copyable, and CANNOT be transferred between threads, because it
logically contains a thread context.  I.e. it does not have value semantics
and should never be treated as a value.  Reraising it in a handler causes
the original exception to be propagated further.

The second is an encapsulation of information about the event.  This DOES
have value semantics, and is sufficient to be used to raise ANOTHER event
(possibly in another thread) that looks very similar to the original one.
But reraising it under those circumstances does not reraise the original
exception, and cannot.

My understanding is that C++ (like many other languages) deliberately did
not specify which of these two was being use, to allow for maximum
flexibility.  While a single thread is involved, that is feasible, but
allowing exception objects to be copied between multiple threads exposes
the semantic differences.  In particular, the context of the original
exception must be cleaned up no later than when the exception is copied
between threads.

Maybe I have misunderstood, but I don't think I have.

Regards,
Nick Maclaren.