1638273 - nsThreadManager::NewNamedThread calls PR_SetCurrentThreadName twice

Status: NEW

(Core :: XPCOM, enhancement)

Description

[David Teller [:Yoric] - still alive but not very active]

Probably not a big deal, but I stumbled upon this while investigating bug 1630898.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

I don't think this matters much, as the calls should be idempotent.

FWIW I believe the two calls referenced here are first the call to NS_SetCurrentThreadName in nsThread::ThreadFunc (https://searchfox.org/mozilla-central/rev/ef5dad8c11a556acd68ca3b9dcd77b226e0aaa29/xpcom/threads/nsThread.cpp#360), and then the call from within the profiler when registering the thread (https://searchfox.org/mozilla-central/rev/ef5dad8c11a556acd68ca3b9dcd77b226e0aaa29/tools/profiler/core/platform.cpp#6323), which will happen here: https://searchfox.org/mozilla-central/rev/ef5dad8c11a556acd68ca3b9dcd77b226e0aaa29/xpcom/threads/nsThread.cpp#375.

Theoretically, we could fix this by making ThreadRegistry::Register check if the current thread is a normal nsThread, rather than checking for the main thread, like:

  // Set the thread name (except for XPCOM threads, which are controlled elsewhere).
  if (!aOnThreadRef.UnlockedConstReaderCRef().Info().IsMainThread() && !nsThreadManager::get().IsNSThread()) {
    // Make sure we have a nsThread wrapper for the current thread, and that
    // NSPR knows its name.
    (void)NS_GetCurrentThread();
    NS_SetCurrentThreadName(
        aOnThreadRef.UnlockedConstReaderCRef().Info().Name());
  }