[cpp-threads] Thread API interface tweaks

Peter Dimov pdimov at mmltd.net
Tue Aug 29 12:25:55 BST 2006


Alexander Terekhov wrote:
> On 8/28/06, Peter Dimov <pdimov at mmltd.net> wrote:
> [...]
>> future<R> provides storage for the return value (or the exception).
>> task<Fn,
>
> Or cancel indication (if Fn can throw thread_cancel aka
> thread_exit_request<thread_canceled>). A future should better know the
> throw spec of Fn and ensure that only specified exceptions (if any;
> implicit "..." by default for functions without throw specs aside for
> a moment) are caught and transported across threads. Also, you better
> turn thread_cancel raised (caught-and-finalized if Fn can throw it
> according to throw spec) in the context of "future" invocation into
> bool future's canceled() state.

The current design treats a cancellation exception no different than any 
other exception; that is, operator() throws a cancellation exception when 
the thread executing the task has been cancelled.

This introduces an ambiguity since operator() can block and be itself 
cancelled. That's why there is an explicit wait(); when it throws, the 
waiting thread has been cancelled. After a successful wait(), if operator() 
throws a cancellation exception, it has come from the other side. 




More information about the cpp-threads mailing list