From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-26 16:04:53
On Mar 26, 2007, at 3:51 PM, Roland Schwarz wrote:
> Howard Hinnant wrote:
>> 1. Owner to t: I'm no longer interested in your computation (but
>> somebody else might be).
>> 2. Owner to t: I want you to clean-up and stop as soon as possible.
>
> Aren't we trying to ask for too much?
>
> If we were able to
>
> thread t();
> ...
> t.raise(exception);
>
> throw an exception at a thread, the thread itself can take whatever
> action is sensible at this point. It could just change its current
> path of control, it could stop (after having reestablished all
> invariants), it can propagate the exception to its "parent".
>
> Just let the user decide what is the best strategy for the
> particular thread.
>
> This scheme, while not mentioning cancellation at all is able to
> deliver almost everything cancellation also could. The difference
> "throwing an exception at a thread" is not an all or nothing decision.
Actually your suggestion is a very interesting superset of the
functionality of the proposed C++ cancellation. In a nutshell:
t.cancel() is the same as t.raise(std::thread_canceled)
Beman and Peter have been active in the area of propagating exceptions
from t back through the join. You are the first (that I know of) to
suggest the generalized propagation the other way. :-) Do you have
use cases other than: t.raise(std::thread_canceled)? Any
implementation strategies?
-Howard