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

[N.M. Maclaren]

On Nov 12 2010, Anthony Williams wrote:
>>
>>> With the introduction of exception_ptr and rethrow_exception, it is
>>> possible to transfer exceptions between threads. In itself, this is a
>>> good thing. However, exceptions are not local. The code that handles
>>> the exception may not know that this is an exception that has been
>>> transferred.
>>
>> That's horrific! It is also a stake through the coffin (not just a 
>> nail) of any implementation that attempts to support system-generated 
>> exceptions as C++ exceptions, or even the cleanup of any system state 
>> during handlers.
>
>This facility has been in the C++0x draft for a while now (it was in the
>August 2007 working draft, N2369), and is now in at least two shipping
>compilers: MSVC2010 and g++ 4.4 and later.

I missed that.  Thanks for the pointer.  There must have been some
confusion when I asked the question, unless it was before that -
possibly because people didn't realise the consequences.

But PLEASE note that I am NOT saying that there should be no mechanism
for one thread to pass an exception object to another, but merely that
it needs a proper mechanism and constraints if it is to be implementable
and reliable.

>> The point is that genuine exceptions often include thread-specific data,
>> often of a form that CANNOT be transferred between threads.
>
>This issue (1369) proposes that rethrowing must always copy the
>exception. This would therefore enable such implementations to copy the
>appropriate data in the exception copy constructor.

I am sorry, but you have missed the point!  A significant amount of the
data needed in exception handling is NOT copyable between threads - not
by ANY mechanism!  Sorry, but but the essential affinity of (genuine)
exceptions to their context has been known for decades.

I know that C++ doesn't require the support of anything more than the
use of exceptions as an alternate return mechanism, but it was designed
to permit them to be used for genuine, system-raised exceptions.  This
change forbids that for many important classes of exception.

I have implemented full-functional, multi-threading exception handling
mechanisms, and been involved with others, and I gave the example of
cleaning up GPU state.  You can copy tokens until you are blue in the
face, but the fact remains that a GPU may be accessed only from the
thread that owns it, and that's an end on't.  Such examples are legion.

Yes, you can allow that by having asynchronously interrupting
call-backs, but I can assure you that you really do NOT want to go
there.  I have done that, too, but couldn't do it on current systems
because they don't have any suitable facilities.  And it means that a
thread can't be cleaned up until the last exception object it raised has
been cleaned up.

>>I disagree; there are many uses for passing exceptions between threads.
>In any case I seriously doubt the feature will be removed from C++0x at
>this late stage.

That is probably true :-(  Another nail in the coffin of reliability.
As I said, passing exceptions between threads is one thing - using an
ordinary, unadorned, UNCONSTRAINED copy operation is what I am saying is
a recipe for unreliability.


Regards,
Nick Maclaren.