It's still under discussion. See N2880 and and N2917. The problem
centers around interactions between detached threads and destruction of
function-static objects.
Ah yes. Threads still actively running while we're shutting
down.
I know that my own take has always been that it's undefined
behavior, and that if you have no way to ensure that a thread
will not be active when shutting down, don't detach it; join
before starting shutdown. Supposing it actually matters---in a
lot of cases, the possible "undefined behaviors" are in fact
limited to things that might be acceptable to many programs
during shutdown. Or you don't provide any provisions for
shutdown at all---the only way to stop the program is to kill
it, in which case, no destructors are run. Neither are what
I'd call nice, but both are quick and easy to implement. When
something cleaner is required, it's usually possible, with some
effort, to ensure that all threads reach an "inactive" state
before starting actual shutdown. So while I'm normally a very
strong opponent of anything which may lead to undefined
behavior, I do wonder if the committee isn't spending too much
time trying to define cases that shouldn't occur in well written
code, and are easy enough to avoid if one knows what one is
doing. (And of course, if one doesn't know what one is doing,
then just about everything to do with threading is potentially
undefined behavior.) In other words: if it's a question of
getting the standard out next meeting, with this as undefined
behavior, or waiting a year or so in order to find a perfect
solution (which we won't find anyway), I'd vote for right now.
(Of course, as long as concepts were there, the people working
on anything else had all the time in the world to do the best
job possible
.)
