Bug 32689

Working on adding asserts to RefCounted, I've added more calls to WTF::currentThread() around. This made a problem we had before more pronounced and caused crashes. Currently, thread identifiers in Pthread-based ports are stored in a threadMap which maps them to OS-provided thread handles. WTF::currentThread() automatically generates a new ThreadIdentifier if the current thread does not yet have a map entry. Unfortunately, some OSes (OSX at least, see test in the discussion for bug 25348) reuse thread handles as soon as previous thread terminates. If the thread does not call WTF::detachThread() which removes the map entry, the new thread will have the same ThreadIdentifier which makes comparing them bug-prone. This also causes existing assertion when a new thread is created by WTF::createThread and finds out there is already ThreadIdentifier from the previously existing non-WTF thread. In addition, current WTF::detachThread(ThreadIdentifier) is often called from another thread, which can happen after a thread with given ThreadIdentifier already finished and a new one created, with the same OS handle. If the ThreadIdentifier leaks in threadMap, it may cause detachThread to 'detach' the new thread instead of old one. Proposed modification is to add a thread-specific memory slot to store ThreadIdentifier and remove the ThreadIdentifier from the threadMap in its thread-specific destructor call. Since other thread-specific destructors can invoke 'currentThread()' and re-establish the identifier, trigger the second pass of the destructor which happens after all regular destructors already were called. This way, the threads won't leave their ThreadIdentifiers in the map. Other ports info: Windows threading does not have this issue because it uses unique ThreadIdentifiers supplied by OS. Chromium uses Pthreads or Windows threading so it's covered. So it leaves GTK and Qt ports which also use threadMap, but I don't know GTK not Qt API well enough to provide a fix, and hope the folks who maintain them will be able to see what, if anything, should be done there. For example, if the respected OSes do not reuse thread handles then there is no problem. This patch will enable another attempt to fix bug 31639.