-
Notifications
You must be signed in to change notification settings - Fork 592
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 task yield #855
remove task yield #855
Conversation
So an 8.5% improvement. This is certainly meaningful. I will trust your and @stebet's judgment on the need to yield. |
Reverted by aa5e8cb |
I'd like to understand how this pervents the deadlock, but I haven't been able to find a test case to reproduce it. (I'd like to add one if there isn't. So it is clear to everyone why it is needed) |
This is something @danielmarbach and / or @bording should weigh in on if they have time. No hurry at all. |
I looked at the current implementation on master and I think the changes proposed here should be fine. If I recall correctly (and I doubt that given my bad memories) we basically introduced the yield as a precaution. Around the timeframe when the first version of the code was introduced we didn't really have a good possibility to run continuations async other than doing some nasty reflection tricks, or wrap the task completion source TrySet methods with Task.Run or enforce async continuations by doing the |
Re-merge pull request #855 from bollhals/remove.task.yield
Proposed Changes
Removed the task.yield in the Work baseclass as well as the try catch, as there is already a try catch at the callee (Workpool of AsyncConsumerWorkService). This eliminates another chunk of allocations.
Types of Changes
Checklist
CONTRIBUTING.md
document