Howard Hinnant wrote:
t.cancel() is the same as t.raise(std::thread_canceled)
But semantics of cancel is different, no? Cancel is expected to bring the thread down, yes? Not so raise, it just is sending kind of a signal to the thread. (The slot being catch clause).
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?
I implemented a small prototype and used it already in an application. I was not using exceptions at this time, as throwing the exceptions I considered not the hard part. I was seeing this syntactic sugar at that time. More interesting was how to establish the interruptible (or "alertable") state. Al though at that time I implemented it as a strict add on to boost thread, because I just wanted to experiment with the usability of the interface. It could be improved a lot I believe if it were tighter integrated into boost:thread. (I needed to resort to notify_all internally e.g, where the program logic would only demand for notify_one.) I uploaded it to the vault under a name "alertable thread" if my memory is not fading... Roland