Re: [boost] "joinable"

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

-Howard