Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at