Skip to content

Conversation

@eduardo-vp
Copy link
Member

@eduardo-vp eduardo-vp commented Jul 6, 2022

Cleaning up the thread pool native implementation, removing ThreadpoolMgr::UsePortableThreadPool() and ThreadpoolMgr::UsePortableThreadPoolForIO() and assume the calls to those functions to always return true.

Deleting all the functions and code that became unused.

@ghost ghost assigned eduardo-vp Jul 6, 2022
@ghost ghost added the area-System.Threading label Jul 6, 2022
@ghost
Copy link

ghost commented Jul 6, 2022

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

Issue Details

null

Author: eduardo-vp
Assignees: eduardo-vp
Labels:

area-System.Threading

Milestone: -

Copy link
Member

@davidwrighton davidwrighton left a 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.

@stephentoub stephentoub marked this pull request as ready for review July 10, 2022 01:18
internal static extern void FreeNativeOverlapped(NativeOverlapped* nativeOverlappedPtr);

[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern OverlappedData GetOverlappedFromNative(NativeOverlapped* nativeOverlappedPtr);
Copy link
Contributor

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.

Copy link
Member

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.

@deeprobin
Copy link
Contributor

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();
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member

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.

@jkotas
Copy link
Member

jkotas commented Jul 11, 2022

Just out of interest: Could you maybe provide some benchmarks? Just to make sure there are no major regressions.

@deeprobin This is result of several years long effort. It was benchmarked extensively along the way, see for example #64834 , #71864 , #38225 .

@kouvel kouvel added this to the 8.0.0 milestone Jul 12, 2022
@kouvel
Copy link
Contributor

kouvel commented Jul 12, 2022

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.

@stephentoub stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Jul 12, 2022
Copy link
Contributor

@kouvel kouvel left a 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;
Copy link
Contributor

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkotas jkotas removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Aug 20, 2022
Copy link
Contributor

@deeprobin deeprobin left a 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 👍🏼.

@jkotas jkotas merged commit bcd44bf into dotnet:main Aug 21, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Sep 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants