Only get Thread.CurrentThread once in PerformIOCompletionCallback#21320
Only get Thread.CurrentThread once in PerformIOCompletionCallback#21320benaadams wants to merge 2 commits intodotnet:masterfrom
Conversation
That's my concern. Since @kouvel merged your other PR that did something similar with the worker dispatch loop, he can make a call on this, too. What impact does this have on throughput? |
|
Hmm... let me look at this again coreclr/src/System.Private.CoreLib/src/System/Threading/Overlapped.cs Lines 116 to 117 in ca56b02 and the contexts involved should only be default, so a |
|
Was changed in #18360 to also skip saving the context for default context, but should be running on that version so the EC Run is coming from elsewhere (though that could be an issue as neither execution is guaranteed to be on a clean context; nor are any context changes undone that are made in the callback; for both unsafe or Default) |
|
Opened #21327 instead as I don't think its currently doing the correct thing |
|
Found what's using the EC Run https://github.com/dotnet/corefx/issues/32582 |
2 participants
Accessing
Thread.CurrentThreadon each pass of the loop (viaExecutionContext.RunInternal) is a significant contributor ofPerformIOCompletionCallback(when the callback is fast)This can be cached and reused for the loop in the same way
ThreadPool.Dispatchdoes.Am assuming it doesn't need the exception handling EC restore semantics that
ExecutionContext.RunInternalprovides as its just throwing the exception into the wind (as perThreadPool.Dispatch)/cc @stephentoub not sure if this is spilling out of ExecutionContext too much?