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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-27 12:35:52

Howard Hinnant wrote:
> On Mar 27, 2007, at 12:00 PM, Peter Dimov wrote:
>
>> 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();
> }

This still destroys the old value of 'launch' implicitly on each iteration 
by assigning it a new value.

The context for my question is that if we are concerned about deferring the 
cleanup until ~thread, then there must exist legitimate use cases that do 
detach() and then don't immediately destroy or reuse the 'thread' variable. 
If such cases don't exist - and I don't see how they could, as there are 
nothing you can do with the thread object after detach except reuse it - 
then deferring the cleanup is not a cause for concern as it will still 
occur.

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.