This implementation is very basic on purpose. I plan to add support for more platform in follow-up PRs.

• On Linux, set_name() does nothing if the name is longer than 15 bytes. Should the function truncate silently to 15 bytes instead? I don't think that raising an exception is very convenient here.
• Setting Thread.name after Thread.start() doesn't call again set_name(). set_name() is called only once per thread, at startup.
• I didn't add automated tests since I don't want to add a get_name() function (use Thread.name to get a thread name).

Demo 1 (main thread):

$ ./python
>>> import os
>>> pid=os.getpid()
>>> with open(f"/proc/{pid}/task/{pid}/comm") as fp: print(f"comm = {fp.read()!r}")
... 
comm = 'python\n'

>>> import _thread; _thread.set_name("demo")
>>> with open(f"/proc/{pid}/task/{pid}/comm") as fp: print(f"comm = {fp.read()!r}")
... 
comm = 'demo\n'

Demo 2 (thread):

$ ./python
>>> import threading, os, time
>>> os.getpid()
81921
>>> t=threading.Thread(target=time.sleep, args=(60,), name="sleeper")
>>> t.start()
^Z

$ cat /proc/81921/task/81927/comm 
sleeper

See also a previous attempt to implement the feature: #14578

I didn't add automated tests since I don't want to add a get_name() function (use Thread.name to get a thread name).

I changed my mind and added a private _thread._get_name() function for tests.

@pitrou @encukou @serhiy-storchaka: Would you mind to review this change? It's to set the thread name in threading.Thread to the operating system.

On Linux, set_name() does nothing if the name is longer than 15 bytes. Should the function truncate silently to 15 bytes instead? I don't think that raising an exception is very convenient here.

I modified _thread.set_name(name) to truncate name to 15 bytes on Linux.

Truncating the string in threading.Thread would be more complicated since it requires to encode the string the filesystem encoding, detect the operating system (Linux), and hardcode the 15 bytes limit there. IMO it's more convenient to truncate in _thread.set_name().

@encukou: I addressed your reviews. Please review the updated PR.

I added tests on long names and non-ASCII names.

@encukou: Maybe the "replace" error handler can be used, instead of not setting the name if the name cannot be encoded to the filesystem encoding. What do you think?

You can use FS_NONASCII. You can also use TESTFN_UNDECODABLE to test that it works with arbitrary bytes and TESTFN_UNENCODABLE to test for encoding error.

Is it a hard limit for the size? Is it the same on other platforms? I would prefer to use a named constant instead of magic numbers 15, 16, 17.

@serhiy-storchaka:

Is it a hard limit for the size?

Yes. Using a longer name fails with ERANGE.

Is it the same on other platforms?

It's 16 bytes on Linux and 64 bytes on macOS, so no, it's not the same.

I would prefer to use a named constant instead of magic numbers 15, 16, 17.

I failed to find a public constant for these limits. For example, Darwin MAXTHREADNAMESIZE constant is private (I'm not 100% sure, but I don't have macOS so I cannot check manually, I only read the code).

You can use FS_NONASCII. You can also use TESTFN_UNDECODABLE to test that it works with arbitrary bytes and TESTFN_UNENCODABLE to test for encoding error.

Ok, I added tests using FS_NONASCII and TESTFN_UNENCODABLE.

AFAIK, to support cross-compilation, configure is limited to compiling & linking. It shouldn't run the built code.

Well, then hardcoding limits for known platforms is okay. We could also determine it at runtime, but this would be too complicated.

On Linux, the thread name can be retrieved by reading /proc: see my examples #127338 (comment).

It is the content of the file, not its name. There is a flaw in this example: what encoding do you use to decode it? How do you read the name of the thread in other process with different locale?

@serhiy-storchaka: I addressed your review, please review the updated PR.

@serhiy-storchaka:

It is the content of the file, not its name. There is a flaw in this example: what encoding do you use to decode it?

open() uses the current LC_CTYPE locale encoding by default. _thread.set_name() uses the filesystem encoding.

How do you read the name of the thread in other process with different locale?

You have the same problem with file content. It's not a new problem.

IMO the Python filesystem encoding is a better choice than UTF-8 for the thread name.

You have the same problem with file content. It's not a new problem.

It is only a large problem if you use locale encoding for file content. If you use a fixed encoding (e.g. UTF-8) or write encoding as a metadata before writing thee encoded content, it is not a problem or a lesser problem.

I am sorry I didn't get to this earlier; on Solaris, the tests are green and all works as expected.

There is one small issue with Solaris detection in test_set_name and I opened #132012 to resolve that.