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