-
Notifications
You must be signed in to change notification settings - Fork 1k
fix: use ConfigureAwait(false) on every await #787
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #787 +/- ##
=======================================
Coverage 74.70% 74.70%
=======================================
Files 72 72
Lines 8465 8465
=======================================
Hits 6324 6324
Misses 2141 2141
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
|
This is absolutely better overall, but it does only cover up the real bug. The "point" of the TarInputStream async implementation is that it's supposed to run entirely sync when being called with This should mean that a deadlock would never occur. Adding the I will keep the |
|
If I find time I will take a look at the generated IL (never had that done before) to see, if Thank you for merging! |
See https://devblogs.microsoft.com/dotnet/configureawait-faq/
General purpose libraries should always use
.CongfigureAwait(false)to avoid deadlocks. It may not prevent from every deadlock but is after all a "best practice".I also added a
.globalconfigto warn ifConfigureAwaitcalls are missing in future changes.Fixes #786
I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.