fix: Prepare ThreadPool for .Net11+ - #3351
Conversation
| { | ||
| // The semaphore Dotnet uses for its own threadpool is more efficient than what's publicly available, | ||
| // but sadly it is internal - we'll hijack it through reflection | ||
| Type lifoType = Type.GetType("System.Threading.LowLevelLifoSemaphore")!; |
There was a problem hiding this comment.
Can we copy/paste the code instead?
Reflection doesn't necessarily work on all platforms and it certainly won't if we ever support Native AOT.
There was a problem hiding this comment.
If we end up copying it, I'd wait for the final release of .NET 11, or else we are obligued to watch if they ever change it, correct bugs, redesign it, etc. (which may very well happen since it's still in preview)
Edit: ...or at least the RC
There was a problem hiding this comment.
Can we copy/paste the code instead? Reflection doesn't necessarily work on all platforms and it certainly won't if we ever support Native AOT.
FYI, we do support Native AOT already since PR #3204 (not only for iOS but also desktop).
It's even tested regularly.
There was a problem hiding this comment.
How did the tests no fail in such case? Or is it not part of tests triggered by PR changes?
There was a problem hiding this comment.
AOT does support reflection, it doesn't support generating new IL on the fly, so no generics like Type.MakeGenericType() basically
There was a problem hiding this comment.
From what I remember, you need to be able to access the type of the class you want to access through that API, here the type is internal
There was a problem hiding this comment.
From what I remember, you need to be able to access the type of the class you want to access through that API, here the type is internal
That's only true on .NET 9 and lower.
There was a problem hiding this comment.
AOT does support reflection, it doesn't support generating new IL on the fly, so no generics like
Type.MakeGenericType()basically
Yes. I think in my mind I had a simpler rule about reflection because in some cases, the related types could have been trimmed. However, in the present case, it's part of the framework so unlikely to be trimmed.
Maybe there is no issue after all.
There was a problem hiding this comment.
@ds5678 cool stuff, thanks! Do you happen to know whether there is a way to validate unsafe accessor mappings without running them - we need to know whether those method exist for the fallback, I could call them with a null instance and filter based on if I get a nullref exception but that's... kind of awful
There was a problem hiding this comment.
If the target member cannot be found, I think the runtime implements it as throwing MissingMethodException (or similar).
I don't know of any way to check if a method is available other than with a try catch block and caching the result.
5 participants
PR Details
See #3326
Very minor changes to the dispatcher as well to make the logic a bit more readable and reduce the cruft.
Related Issue
fixes #3326
Types of changes
Checklist