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. 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. Christof -- okunah gmbh Software nach Maß Zugspitzstr. 211 www.okunah.de 86165 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055