Re: [boost] "joinable"

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-05-30 09:39:16

Anthony Williams:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> Anthony Williams:
>>
>>> I have thought about providing an "interrupt handle" which you can
>>> obtain either from a boost::thread object, or by calling
>>> boost::this_thread::get_interrupt_handle() or similar, in which case a
>>> detached thread would be interruptible.
>>
>> At this point how far would you be from N2178? It does give you this 
>> exact
>> functionality, and in addition, one gets always-joinable handles that 
>> keep
>> referring to its thread unless assigned something else.
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2178.html
>
> Well, the interface is rather different for one thing, N2178 being
> primarily free functions operating on handles, rather than member
> functions on a class.

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.

> 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.

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.)