Re: [boost] Boost.Threads, N2178, N2184, et al

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