[cpp-threads] Re: Exception propogation across threads

[Peter Dimov]

Lawrence Crowl wrote in message c++std-ext-8666:

> The drifting consensus of this discussion is likely to inhibit the
> exploitation of C++ threads and leave them in the realm of "useful
> to server software but not to desktop software".  My thesis is that
> to effectively exploit software, programmers must be able to easily
> convert sequential code to parallel code and back.  An exception
> model that does not support this conversion will slow adoption of
> parallelism and force system vendors into high-frequency,
> high-power chips.
>
> To be concrete, suppose I have a chunk of code like:
>
>    a = f( b );
>    c = g( d );
>    e = h( a, c );
>
> Knowing that the calls to f and g do not interfere, I need which
> to be able to convert to a parallel execution of those.  This can
> be done (with the syntax of N1875) as:
>
>    auto join t = f( b );
>    c = g( d );
>    e = h( join t, c );
>
> But _only_if_ any exceptions within the functions are preserved.

You're (1) equating physical threads of execution with asynchronous parallel 
tasks, (2) focusing on exception propagation while ignoring the propagation 
of the return value, which is likely to be more important.

We've been trying to address this issue with another component (called 
future or task in the different proposals) whose job is to represent a 
future result and move the return value or the exception from the callee to 
the caller. Given a future and taking some liberties in syntax, your example 
could look like:

future<A> a = async( f, b );
c = g( d );
e = h( a, c );

where it is an implementation detail of async() how the asynchronous tasks 
are mapped to the underlying physical threads managed by its default 
"executor", likely some variation of a thread pool.

The actual syntax of obtaining an A from a future<A> (a, a(), a.get()) and 
the precise semantics of future<> are still up in the air, but several of us 
are determined to pursue, refine and propose it, even though the committee 
has decided that it belongs in a technical report, rather than in the C++0x 
standard. On the bright side, this would give us time to get it right.