Le 25/10/12 10:33, Christof Donat a écrit :
Hi,
The third situation below shows a non blocking ~future. But such execution is *disallowed *by the standard because the completion of launched thread would not synchronize with the last release of the shared state.
The big question is: why?
Can't the destructor detach from the shared state and let the state be cleaned up by the launched thread?
That is what I thought in the first place as well. Yet, the object to destroy will live on the stack of the main thread. Why?
Before the function can return, the stack frame has to be released and therefore the objects in it have to be destroyed. When the destruction is done by the launched thread, either the main thread has to wait and there is nothing you can gain that way, or the stack would need to be forkable. That would break almost all C++ ABIs around the world, I guess.
Best, Vicente