Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2008-05-28 13:43:10

On May 28, 2008, at 1:25 PM, vicente.botet wrote:

> ----- Original Message -----
> From: "Anthony Williams" <anthony.ajw_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Wednesday, May 28, 2008 5:04 PM
> Subject: Re: [boost] "joinable"
>> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>>> just a question that could clarify my thoughts, can a non joinable
>>> thread
>>> be
>>> interruptible?
>> No, because you no longer have a handle with which to interrupt it.
>> 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.
> Ok, the question now is *should* the joinable and interruptible
> features of
> a thead be disociated?
> IMO they should. We can need to interrupt a thread even if we are no
> interested when the thread finish.
> If should be better if the the implementation is possible, but I
> don't think
> that this is a big problem for the user. Most of the applications
> could work
> without releasing the resources that are released when a thread is
> detached,
> and preserv attached the thread if they want to be able to interrupt
> it,
> isn't it?

This sounds like something that should be layered on top of
boost::thread, not embedded in it. boost::thread is conceptually a
unique-owner situation: A single handle (boost::thread) refers to a
single resource (a thread of execution). An owner should be able to
do things to that resource without worrying about interference from
others. If you're looking at a function with a boost::thread in it,
you don't want to have to do a whole program analysis to figure out if
the thing might get interrupted out from under you.

thread f(thread t)
    // is it safe to play with t in here?
    return move(t);

I'm not saying you don't need the capability of multiple interruption
handles. All I'm saying is this functionality should be put into
another type, like shared_future (where one expects - and knowingly
pays for - ownership/control to be shared).


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