-
Notifications
You must be signed in to change notification settings - Fork 347
Conversation
myget seems unhappy
|
private static TaskRunScheduler _taskRunScheduler = new TaskRunScheduler(); | ||
private static InlineScheduler _inlineScheduler = new InlineScheduler(); | ||
|
||
public static Scheduler TaskRun => _taskRunScheduler; |
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.
ThreadPool
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.
Done
myget issue https://github.com/dotnet/coreclr/issues/15769 |
64916f6
to
cc7549e
Compare
{ | ||
((Action)state)(); | ||
} | ||
catch (Exception ex) |
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.
Do you want to catch the Exception? Currently assuming so as side-effect is quite bad - however is it always wrapped (for logging etc)
What are we doing with this PR? We have an API review of these APIs on Friday (I think) and it would be good to merge or close this one before. |
Its just shooting yourself in the foot; perf-wise, not to use |
@@ -5,8 +5,11 @@ namespace System.Threading | |||
{ | |||
public abstract class Scheduler | |||
{ | |||
public static Scheduler TaskRun { get; } = new TaskRunScheduler(); |
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.
Why this change?
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.
Because you said so here #2026 (review)
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.
Should have been more specific, why the syntax change.
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.
Storing it in a Scheduler
field means the exact type gets lost for:
Scheduler.ThreadPool.Schedule((() => {})
So it remains a virtual call.
Storing it in an exact type field ThreadPoolScheduler
means when Scheduler.ThreadPool
inlines the Jit knows exactly what it is and can devitalize it to a direct call.
Won't directly help pipelines as the Pipe
stores the configured values in a Scheduler
field; but will help anyone calling it directly.
#elif NETSTANDARD2_0 | ||
Threading.ThreadPool.QueueUserWorkItem(_actionAsTask, action); | ||
#else | ||
Task.Factory.StartNew(action); |
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.
Should this just be QueueUserWorkItem (I'm aware it ends up going to the global queue).
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.
Doesn't exist on netstandard1.1
came in at netstandard2.0
😢
@@ -2,7 +2,7 @@ | |||
<Import Project="..\..\tools\common.props" /> | |||
<PropertyGroup> | |||
<Description>An abstraction for doing efficient asynchronous IO</Description> | |||
<TargetFramework>netstandard1.1</TargetFramework> | |||
<TargetFrameworks>netstandard1.1;netstandard2.0;netcoreapp2.1</TargetFrameworks> |
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 probably the most unfortunate part of this change but meh..
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.
Meh indeed. It's in implementation details with zero bearings on the user's experience.
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.
It's in implementation details with zero bearings on the user's experience.
In this case yes.
{ | ||
// Create faulted Task for the TaskScheulder to handle exception | ||
// rather than letting it escape onto the ThreadPool and crashing the process | ||
Task.FromException(ex); |
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 pretty atypical. I think it should be left to crash. We don't do this anywhere else.
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.
K, will clean up the code a lot to remove it
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.
Removed
bb36d0f
to
89322e7
Compare
Scheduler Devirtualization
TaskRunScheduler
andInlineScheduler
TaskRunScheduler
andInlineScheduler
in derived typed members; rather than base typeResolves: #2027
Fast Fire-and-Forget Tasks for
TaskRunScheduler
ThreadPool
; when available, rather than have the extra overhead of aTask
which is ignored.QueueUserWorkItem(preferLocal: true)
which is lower contention and more closely matchesTask
behaviour dotnet/corefx#12442Action
fails create a failedTask
so it can be captured as an unobserved task exception as perTask.Run
Resolves: #2002
Rename TaskRun -> ThreadPool #2026 (review)
/cc @davidfowl @pakrym