Boost logo

Boost :

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

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.

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