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

[N.M. Maclaren]

On Nov 15 2010, Boehm, Hans wrote:
>
>I still think the issues raised by Nick are really different.
>
> If the exception requires local cleanup (e.g. the GPU state), it should 
> clearly be caught locally, and the cleanup should be performed locally, 
> and then another exception should be rethrown to pass it across threads. 
> C++0x lets you do that, e.g. by catching the exception inside the async 
> function. And I don't know how to do better.

I am not disagreeing with you there.  What I am gibbering about is the
deceptiveness of providing mechanisms that assume value semantics for
events that do not always have them.  That is a recipe for unreliable
exception handling.

> Although debugging cross-thread memory smashes is a serious pain, I think 
> the alternative renders the language largely unusable for general 
> concurrent programming. It's not hard to find instances of perfectly 
> reasonable cross-thread memory modification in existing C and C++ code, 
> for precisely this reason.

The decision to allow it was taken a long time ago - probably about 1990.
Whether or not it was a mistake, the boats have been burnt.

> Currently the C++0x draft requires this sort of cross-thread memory 
> access to work, while the C1x draft does not. This makes some sense, 
> since C caters to more special purpose embedded applications that may 
> have odd requirements, and may be able to live without parallel 
> algorithms that work on stack-allocated data. But I would be surprised if 
> there were server or workstation C1x implementations that really 
> prohibited cross-thread memory access.

Prepare to be surprised.  I have used at least more than one, and believe
that there are several around.  HOWEVER ....

The memory that only the owning thread may access is not allocated by the
normal C++ mechanisms, in the cases that I have seen.  This is my point
about needing action to convert an exception from its original form to a
form that has value semantics (and is no longer the original exception,
but merely one that looks the same).

I am surprised about your reference to "stack-allocated data".  I don't
see how you can allow "value semantics" exceptions to contain any references
to the stack of the thread that raised the exception and allow them to be
passed as data to other threads, without a lot of extra constraints that I
can't find in the standard.  I may have missed those, of course.


Regards,
Nick Maclaren.