[cpp-threads] Thread API interface tweaks

Alexander Terekhov alexander.terekhov at gmail.com
Tue Aug 29 14:53:23 BST 2006


On 8/29/06, Peter Dimov <pdimov at mmltd.net> wrote:
> Alexander Terekhov wrote:
> > On 8/29/06, Peter Dimov <pdimov at mmltd.net> wrote:
> > [...]
> >> 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.
> >
> > And this introduces an ambiguity race. No?
>
> Nope, operator() never blocks after wait() has finished, since there is a
> result/exception available. ready() is a postcondition of a successful
> wait().
>
> > What about try_wait()? Does it throw cancel or not?
>
> No, try_wait (spelled 'bool ready() const') is non-blocking and hence,
> non-cancellable.

Ah. Okay. Now if you can make your future's operator() translate
remote thread_cancel exception into future_canceled exception (when
remote thread cancel wins the race), enable me to inspect the union
without throwing/catching any exceptions, then I'll be totally happy.

regards,
alexander.



More information about the cpp-threads mailing list