Re: [boost] Boost.Threads, N2178, N2184, et al

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-26 14:09:10

On Mar 26, 2007, at 1:56 PM, Stefan Seefeld wrote:

> Howard Hinnant wrote:
>
>> Fair point.  Perhaps we should go back to a more fundamental  
>> question:
>>
>> std::thread t(f);
>> ...
>> t.cancel();  // Logically is this a const or non-const operation on
>> the thread executing t/f?
>>
>> To answer that question probably involves the very definition of
>> cancellation.  The "t.cancel()" can reasonably be interpreted in two
>> different ways:
>>
>> 1.  Owner to t:  I'm no longer interested in your computation (but
>> somebody else might be).
>> 2.  Owner to t:  I want you to clean-up and stop as soon as possible.
>
> Isn't the first point more in line with what in POSIX threads is
> described by a 'detach' ? (once a thread is detached, it can't be
> joined any more. It still can be canceled.

I was thinking about that when I wrote this list and decided not  
quite.  Detach is more reasonably interpreted as:  I want you to  
continue to work independently.  Clean up after yourself when you're  
done.

I.e. with 1 I'm trying to convey that I don't care whether the child  
thread lives or dies, does more work or not.  Whereas with 2 I'm  
trying to say that I don't want the child to do any more work.  And  
with detach I'm trying to say, I want you to continue your work, just  
I'm going elsewhere, turn out the lights when you're done.

In the pthreads world, there is no direct support for 1.  And 2 maps  
to pthread_cancel.

-Howard