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