On Mar 27, 2007, at 12:52 PM, Peter Dimov wrote:
Howard Hinnant wrote:
On Mar 27, 2007, at 12:35 PM, Peter Dimov wrote:
Once there, we may (or may not) opt to actually make the thread
object useful after detach because this pattern currently has no
other uses. This
leads us directly to the 'detach suppresses cancel but has no other
effects'
model, where you can still query the id of the detached thread,
among other things, if you hold onto the object for a while.
What would join() do after detach() in this model?
What it always does. Wait for the thread to end, then return.
Ok, thanks I think understand now. New use case: vector<thread> v; ... fill with threads ... for (auto i = v.begin(), e = v.end(); i != e; ++i) if (i_feel_like_it) i->detach(); ... // need new thread now, go look for a detached one and use it auto i = v.begin(); for (auto e = v.end(); i != e; ++i) if (i->is_detached()) // N2184 spells this i->get_id() == thread::id() break; if (i != v.end()) *i = std::thread(f); // recycle detached thread else v.push_back(std::thread(f)); In this use case, you're still recycling threads, as in my previous use case. But here there is an opportunity for many threads to not get recycled for a long time, and perhaps forever. <sigh> And this use case is making me nervous about join not implicitly detaching... -Howard