Regression 1.3.3 => 1.4.0: Deadlock when using TarInputStream.GetNextEntry() in WPF application

[flensrocker]

Steps to reproduce

This is part of a large WPF application (.NET Framework 4.8), I have to build a small reproduction. I just want to mention this issue in case someone has the same problem.

Expected behavior

TarInputStream.GetNextEntry() should not deadlock when used on the main thread.

Actual behavior

TarInputStream.GetNextEntry() blocks when called on the main thread of an WPF application. In the PR #746 for the async streams I see a lot of .GetAwaiter().GetResult(). This is not a recommended practice, see https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md#warning-deadlocks

Version of SharpZipLib

1.4.0

Obtained from (only keep the relevant lines)

• Package installed using NuGet

[flensrocker]

It happens when I wrap the TarInputStream with an GZipStream.

See this small reproduction sample: https://github.com/flensrocker/SharpZipLibDeadLock

When I downgrade SharpZipLib to 1.3.3 it won't lock.

[piksel]

Thanks for a thorough report! I will investigate this further...

[flensrocker]

I took a look at TarInputStream and TarBuffer, but I don't have a good idea how one can separate the sync and async parts (after all, it's "just" the Read* methods which are async), so both sync & async can be provided, without copying the code surrounding the async calls.

I will think about it from time to time and will report any progress if I come up with something.

[flensrocker]

Adding .ConfigureAwait(false) to every await seems to fix my issue.

After all it's a "best practice" for general purpose libraries, see https://devblogs.microsoft.com/dotnet/configureawait-faq/