On Mar 27, 2007, at 12:00 PM, Peter Dimov wrote:
Howard Hinnant wrote:
I believe one of the big differences is : How soon after join() can the thread clean up resources? I.e. the model I've been working on has an implicit detach() inside of join(), for the purpose of cleaning up the resources immediately instead of waiting to ~thread() for resource cleanup.
One question that comes to mind here - which I've been unable to effectively communicate in my other post - is:
What use case exists for not destroying the thread object after it's been detached (or joined+detached) under the current N2184 semantics?
Perhaps a deamon spawner? Perhaps one that has other communication lines with the detached thread? vector<function<void()>> queue; std::thread launch; while (!queue.empty()) { launch = std::thread(queue.back()); queue.pop_back(); register(launch.get_id()); launch.detach(); } The start function in the queue may unregsiter(id) when the thread ends. We could've put launch inside the loop and thus done without the explicit detach. But I'm lacking motivation to disallow the above pattern. Maybe the detach is conditional and the thread needs scope external to the loop: vector<function<void()>> queue; std::thread launch; while (!queue.empty()) { launch = std::thread(queue.back()); queue.pop_back(); register(launch.get_id()); if (something) break; launch.detach(); } // work with undetached launch thread here -Howard