Re: [boost] Boost.Threads, N2178, N2184, et al

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