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
>> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk