Open piju3 opened 10 months ago
Tagging subscribers to this area: @mangod9 See info in area-owners.md if you want to be subscribed.
Author: | piju3 |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Threading` |
Milestone: | - |
Platforms that don't have a thread name property could return null instead of throwing an exception.
In my experience thread names are primarily a diagnostic/debugging aid, and so would just silently ignore the inability to set a thread name.
Background and motivation
On many platforms (including at least Windows, Linux and FreeBSD), a system thread can define a "name" for itself, which can be read by other processes. These names are useful for external tools such as debuggers or system activity monitors (like htop), and can help identify what internal tasks are using most processor time.
In Linux and FreeBSD this corresponds to pthread_setname_np and pthread_getname_np (or, in Linux, the /proc/[tid]/comm file). In Windows this corresponds to SetThreadDescription and GetThreadDescription.
.NET already has the Thread.Name property for internal threads, which sets those properties for the corresponding operating system thread. It also has Process.ProcessName which can get the equivalent name for any system process. But there is no corresponding ProcessThread.ThreadName.
It's true that threads are a low level tool, and most programmers should generally not deal with them directly, but there are still many situations where they might be important to deal with. As an example, I recently had to write a custom "CPU monitor" for a legacy application that manually spawns multiple threads, and ended up implementing this method myself.
API Proposal
If a platform does not have this concept, the method would just throw PlatformNotSupportedException.
API Usage
Alternative Designs
Risks
No response