"Peter Dimov" <pdimov@pdimov.com> writes:
The "interrupt handle" is very similar to thread::handle. The allowed operations on a thread::handle are cancel/interrupt and join/wait; and if you follow through with the "interrupt handle" idea you'll eventually see that many of the use cases in which you need an "interrupt handle" also require a "wait handle" as well. Once you add the ability to wait on an "interrupt handle", there are no differences left.
Possibly.
Also, I quite like the single-ownership property of boost::thread and std::thread.
"Ownership" doesn't quite apply to a thread, in the usual resource-management sense of the word, in which the thread basically owns itself.
In the "thread manager" sense, allowing observers to wait for a thread to end does not compromise your ownership of that thread. Giving foreigners the ability to interrupt one of your threads can, if you consider control over when a thread terminates part of your ownership.
Yes, and this is the bit that makes me wary about providing interrupt handles.
In this latter case, either you execute foreign code in your thread, or not. If you don't, nobody can obtain a handle to your thread, and your ownership is still absolute. If you do, things get more hairy, since you usually want to give the client who submits the task the ability to cancel it. We don't have a good solution to this problem yet, in any of our proposals (an "interrupt handle" with an expiration date.)
In order to cancel just a task we need to have an handle that can be used to cancel just that task, whatever thread it happens to be running on, without affecting other tasks running on that thread. Just thinking this through suggests to me that we could use the ability to install a new interrupt handle from within a thread. We could provide something like: template<typename Callable> bool call_interruptibly(interruption_handle h,Callable f); In which interruption on the handle h (and ONLY on the handle h) will trigger an interruption at the usual interruption points. If the call is interrupted, then this function returns false, otherwise it returns true. All non-interrupt exceptions are propagated normally. This would enable a thread to pass out an interruption handle that only applied to a specific bit of code. This could be used in e.g. packaged_task to allow the task to be interrupted without affecting any other tasks that are running on that thread. get_interruption_handle() would not be provided. Thoughts? Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL