`InterpreterPoolExecutor`'s default thread name prefix is invalid

[aisk]

Bug report

Bug description:

from concurrent.futures import InterpreterPoolExecutor


def w():
    import time
    time.sleep(100)

executor1 = InterpreterPoolExecutor()
executor1.submit(w)
executor1.submit(w)

executor2 = InterpreterPoolExecutor()
executor2.submit(w)
executor2.submit(w)

executor1.shutdown()
executor2.shutdown()

With this code, htop with "Show custom thread names" enabled) shows it's ThreadPoolExecutor instead of InterpreterPoolExecutor:

Other process monitor tools may have the same result if it read the custom thread name from OS.

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS, Linux

Linked PRs

• gh-136470: Correct InterpreterPoolExecutor's default thread name #136472

[ZeroIntensity]

Duplicate of #125920. I'm still not sure what the best way to deal with this is. I think we need to somehow unify the threading interface across all interpreters.

[aisk]

Hi @ZeroIntensity, I think this is not the same issue. I tested #125920's code example, and it's about the threading.current_thread().name not being passed to the sub-interpreter, it's really a issue. But actually, the OS's thread custom name is set.

In this PR, I'm mainly focusing on the default thread name of InterpreterPoolExecutor. For now, it's ThreadPoolExecutor-1 instead of InterpreterPoolExecutor-1.

I updated the issue's tittle for more clairify.

[ZeroIntensity]

I'm not sure it's that useful to have the OS-level name be correct without the Python-level name, but I guess it makes sense to change it.

[aisk]

I think it's useful in some way. I'm testing the sub-interpreter these days, and using htop (with "Show custom thread names" enabled) to check if my code is really using multiple cores, and I found the issue. I guess someone might be confused if they're creating an InterpreterPoolExecutor but see a ThreadPoolExecutor in htop.