Provide a method to retrieve the native handle for a Thread object

[john-h-k]

Background and Motivation

For native interop, it can be incredibly useful to have access to the underlying thread handle value. For example

• Working with native fibres
• Creating custom fibre libraries
• Performing operations like setting thread affinity

Proposed API

public class Thread
{
+    public IntPtr GetNativeHandle();
+    public bool TryGetNativeHandle(out IntPtr handle);
}

GetNativeHandle would throw an exception (not sure which one) if the Thread object wasn't a true thread (currently afaik they all are, but in the future they could be fibers etc), whereas TryGetNativeHandle would return false

Usage Examples

var thread = ...;

// lock the thread to the first logical processor
Win32.SetThreadAffinityMask(thread.GetNativeHandle(), 1);

Alternative Designs

You could, in this case, just expose SetThreadAffinity - but it doesn't make sense if a thread isn't always a "real" thread

Risks

It isn't a breaking change. If misused, I am sure the handle could do some messy things, but that applies to a lot of the framework 😄

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[john-h-k]

cc @tannergooding

[jkotas]

What is this API going to return on non-Windows?

[john-h-k]

I would assume the pthread_t* on linux systems, and on other systems the type the runtime uses to create them with the OS

[mangod9]

@kouvel fyi..

[jkotas]

The problem is that there are typically number of different kinds of thread handles. For example, OSX has pthread_t*, mach_port_t and TID. Even pthread_t* on Linux is not the ubiquitous thread ID. For example, the Linux OS syscalls take pid_t, not pthread_t*.

Working with native fibres
Creating custom fibre libraries

.NET does not work with Windows fibres for fundamendal reasons. This API won't make it possible.

[tannergooding]

Isn't pid_t the process ID and not the thread handle?

[janvorli]

pid_t is used for both process id and thread id (gettid() returns it for current thread, for example)

[tannergooding]

Thanks! For reference: https://man7.org/linux/man-pages/man2/gettid.2.html

In a single-threaded process, the thread ID is equal to the process ID (PID, as returned by getpid(2)). In a multithreaded process, all threads have the same PID, but each one has a unique TID.
...
The thread ID returned by this call is not the same thing as a POSIX thread ID (i.e., the opaque value returned by pthread_self(3)).

[john-h-k]

.NET does not work with Windows fibres for fundamendal reasons. This API won't make it possible.

is it specific to how the win32 fibre implementation works? - or is it fundamentally impossible to use fibres at all in .NET

[jkotas]

or is it fundamentally impossible to use fibres at all in .NET

Correct. We do not support running managed code on fibers. If you run managed code on fibers, you will get arbitrary crashes.

[john-h-k]

If you run managed code on fibers, you will get arbitrary crashes.

Ah, my code already does that so it's fine 😆

[john-h-k]

Being able to do things like set affinity would still be useful, I think. Althought, there could be a managed API to do that specific thing

[HighPerfDotNet]

I think I've run into changed behavior related to this when trying to port .NET Framework application that was successful at setting ideal processor affinity but that no longer works in .NET 5, the following code no longer matches current thread id:

/* --------------------------------------------------------------------------------- */

// note: it's obsolte, but the same value can be had via Thread.CurrentThread.ManagedThreadId -
// giving exact code as it worked for 10+ years.

int iCurThreadID=AppDomain.GetCurrentThreadId();

foreach (ProcessThread oPT in Process.GetCurrentProcess().Threads)
{

if (oPT.Id==iCurThreadID)
{
	oPT.PriorityBoostEnabled=true;
	oPT.IdealProcessor=iProcAffinity;
	oPT.ProcessorAffinity=new IntPtr(1L<<iProcAffinity);
	break;
}

}

/* --------------------------------------------------------------------------------- */

How are we supported to set processor affinity for current managed thread?

[deeprobin]

API-Shape looks good to me.
Imo, we should consider using the CallerMustBeUnsafe (see proposal) attribute.

[deeprobin]

Alternative: A property called NativeHandle, UnderlyingHandle or just Handle to be conform with dotnet/winforms#8833.