On Mar 27, 2007, at 9:45 AM, Peter Dimov wrote:
Howard Hinnant wrote:
[ detach vs join ]
This is a departure from pthread semantics that I am uncomfortable with. If I accidently get myself into this kind of race. I think I'd prefer some noise (an assert, or exception, or crash).
I'm not entirely sure what is the purpose of detach as it's unique to N2184, but if it's only used to indicate "do not cancel on ~thread, please", there is no need for it to actually detach anything (invalidate the pthread_t handle), just set a "don't cancel" flag. The race you describe is then harmless.
The purpose of detach is to model the semantics of pthread_detach. pthread_detach is described as: The pthread_detach() function is used to indicate to the implementation that storage for the thread thread can be reclaimed when that thread terminates. If thread has not terminated, pthread_detach() will not cause it to terminate. The effect of multiple pthread_detach() calls on the same target thread is unspecified. I am exploring tightening up those semantics up just a bit with Anthony's:
t.detach() t.detach() harmless race. Thread is detached. second detach is no-op.
(watch out for the inevitable, unintentional text wrapping) -Howard