-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Remove ThreadPool native implementation #71719
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove ThreadPool native implementation #71719
Conversation
|
Tagging subscribers to this area: @mangod9 Issue Detailsnull
|
davidwrighton
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this. I see a couple of functions called by the AppDomain class which now look unnecessary, but other than that everything looks pretty good to me.
src/coreclr/System.Private.CoreLib/src/System/Threading/Overlapped.cs
Outdated
Show resolved
Hide resolved
src/coreclr/System.Private.CoreLib/src/System/Threading/ThreadPool.CoreCLR.cs
Outdated
Show resolved
Hide resolved
…Pool.CoreCLR.cs Co-authored-by: Stephen Toub <[email protected]>
| internal static extern void FreeNativeOverlapped(NativeOverlapped* nativeOverlappedPtr); | ||
|
|
||
| [MethodImpl(MethodImplOptions.InternalCall)] | ||
| internal static extern OverlappedData GetOverlappedFromNative(NativeOverlapped* nativeOverlappedPtr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about porting the rest of the Overlapped fcalls to managed code? Especially GetOverlappedFromNative whose implementation is trivial (just casting a pointer and a couple of dereferences) would be benefitted from being inlined by the JIT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there are more follow up improvements that can be done here. Not as part of this PR through.
|
I'm currently not that familiar with the internal ThreadPool APIs. But it is a good step into the future that this PR will be merged and the ThreadPool stuff will be converted into managed code. Will we get this merged before the .NET 7 release? Just out of interest: Could you maybe provide some benchmarks? Just to make sure there are no major regressions. |
|
|
||
| #if CORECLR | ||
| #pragma warning disable CA1823 | ||
| private static readonly bool s_initialized = ThreadPool.EnsureConfigInitialized(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason to use an unused field here?
Where is this used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is used to ensure that the threadpool config is initialized. It is the minimal change to preserve the existing initialization flow.
As mentioned above, there are more cleanups that can be done here, not part of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. I was thinking of a static constructor, but of course it works that way too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding regular static constructor would add static constructor triggers to all static methods that may introduce performance regressions.
src/libraries/System.Private.CoreLib/src/System/Threading/PortableThreadPool.cs
Show resolved
Hide resolved
@deeprobin This is result of several years long effort. It was benchmarked extensively along the way, see for example #64834 , #71864 , #38225 . |
|
Marked for .NET 8 for now. The full switchover to the portable thread pool has only completed in .NET 7 and the intention was to leave the fallback switches in place for .NET 7. |
kouvel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few comments, otherwise LGTM, thanks!
|
|
||
| SOSDacLeave(); | ||
| return hr; | ||
| return E_NOTIMPL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SOS ThreadPool command would not work after this, it would need to be updated such that it continues to show info from the portable thread pool when receiving an E_NOTIMPL from this API, while keeping the legacy paths for backward compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Submitted: dotnet/diagnostics#3303
src/coreclr/System.Private.CoreLib/src/System/Threading/ThreadPool.CoreCLR.cs
Outdated
Show resolved
Hide resolved
deeprobin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I can judge: LGTM.
I am looking forward to the change 👍🏼.
Cleaning up the thread pool native implementation, removing
ThreadpoolMgr::UsePortableThreadPool()andThreadpoolMgr::UsePortableThreadPoolForIO()and assume the calls to those functions to always returntrue.Deleting all the functions and code that became unused.