-
Notifications
You must be signed in to change notification settings - Fork 506
Port Perf fixes over from CoreCLR. #4150
Conversation
@jkoritzinsky, |
It looks like I missed a bunch of commits in the issue. There are two PRs with most of the perf changes: dotnet/coreclr#9234 and dotnet/coreclr#9279. They weren't squashed before merging and I initially missed the other commits. Considering that there are currently a significant number of differences between the CoreCLR and CoreRT implementations (with most of the fixes occurring in CoreCLR), I think it would be best to port the CoreCLR implementation of ThreadPool.cs over wholesale except for the few changes that were made specifically to CoreRT. Probably after UWP6.0 though at this point. @sergiy-k, when would UWP6.0 split into a separate branch and master become future? |
I've updated the rest of ThreadPool as well as our implementation of I'll mark this no merge until we know for sure that the UWP 6.0 release branch has been forked. |
The branch has been forked. Feel free to merge once everything works correctly in your change. |
@kouvel Can you take a look and make sure I didn't miss anything? |
// surface to eliminate a dependency on System.Collections.Concurrent. | ||
// Please try to keep this in sync with the public ConcurrentQueue implementation. | ||
// | ||
// =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
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.
Please keep this comment for now
/// This makes a note in the state flags so that we avoid any costly synchronous operations in the finish codepath | ||
/// such as inlined continuations | ||
/// </summary> | ||
/// <param name="delegateRan">Whether the delegate was executed.</param> |
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 changes in this file are not necessary. Anything related to thread abort can be removed, since thread abort is not supported. They can be removed from the .NET Core side later as well.
///// The ThreadPool calls this if a ThreadAbortException is thrown while trying to execute this workitem. | ||
///// </summary> | ||
//void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ } | ||
void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ } |
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.
Stuff related to thread abort can be removed
} | ||
} | ||
} | ||
catch (ThreadAbortException tae) |
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.
Stuff related to thread abort can be removed
Debug.Assert(setSuccessfully, "Should have been able to complete task"); | ||
} | ||
//void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ } | ||
void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ } |
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.
Stuff related to thread abort can be removed
using System.Diagnostics; | ||
using System.Diagnostics.Contracts; | ||
using System.Runtime.InteropServices; | ||
using System.Collections.Concurrent; |
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.
There are still a fair number of differences. Eventually it would be best to put most of the code in the shared folder but for now I think it would be easiest to eliminate all of the insignificant differences and only keep the differences that were intentionally made on the CoreRT side.
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.
LGTM otherwise, thanks!
using System.Diagnostics.Contracts; | ||
using System.Runtime.InteropServices; | ||
using System.Collections.Concurrent; | ||
using System.Diagnostics.CodeAnalysis; |
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.
Please keep the usings sorted
private readonly Object _state; | ||
|
||
internal _ThreadPoolWaitOrTimerCallback(WaitOrTimerCallback waitOrTimerCallback, Object state, bool flowExecutionContext) | ||
internal _ThreadPoolWaitOrTimerCallback(WaitOrTimerCallback waitOrTimerCallback, Object state, bool compressStack) |
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 previous parameter name is better (flowExecutionContext), I believe that name was purposefully used here since compressed stack is not relevant
Fixes #3561.
@kouvel
@sergiy-k
@AntonLapounov