Re: [boost] "joinable"

From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-05-30 10:02:57

"Peter Dimov" <pdimov_at_[hidden]> 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