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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-27 12:18:28

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