[API Proposal]: ProcessThread.ThreadName

[piju3]

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

namespace System.Diagnostics
{
    public class ProcessThread {
       public string ThreadName {get;}
    }
}

If a platform does not have this concept, the method would just throw PlatformNotSupportedException.

API Usage

using System.Diagnostics;
var currentThreads = Process.GetCurrentProcess().Threads.Cast<ProcessThread>();
foreach (var thread in currentThreads)
{
    Console.WriteLine(thread.ThreadName);
}

Alternative Designs

• Platforms that don't have a thread name property could return null instead of throwing an exception.
• I named the property ThreadName for consistency with the existing Process.ProcessName, alternatively just "Name" would be fine.

Risks

No response

[ghost]

Tagging subscribers to this area: @mangod9 See info in area-owners.md if you want to be subscribed.

Issue Details

---

### 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 ```csharp namespace System.Diagnostics { public class ProcessThread { public string ThreadName {get;} } } ``` If a platform does not have this concept, the method would just throw PlatformNotSupportedException. ### API Usage ```csharp using System.Diagnostics; var currentThreads = Process.GetCurrentProcess().Threads.Cast(); foreach (var thread in currentThreads) { Console.WriteLine(thread.ThreadName); } ``` ### Alternative Designs - Platforms that don't have a thread name property could return null instead of throwing an exception. - I named the property ThreadName for consistency with the existing Process.ProcessName, alternatively just "Name" would be fine. ### Risks _No response_

Author:	piju3
Assignees:	-
Labels:	`api-suggestion`, `area-System.Threading`
Milestone:	-

[emaste]

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.