Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-27 13:11:06

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)
// 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() ==
if (i != v.end())
    *i = std::thread(f); // recycle detached thread

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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at