icsharpcode
feature request: full async/await pattern stream support
Expected behavior
I could not find any related topics, except an unanswered issue "CopyToAsync fails with ZipOutputStream #167".
One of c#'s greatest features over other languages is the async/await pattern. The .net streams all support async/await since ver 4.5 and there could be major implications and performance enhancers for FileStream in particular. Is there any plan to implement this support in this library?
So, I had a little bit of a look at this (partly as it's requested, partly out of thinking it might be interesting to tinker with). I initially wondered if it would be possible to start at the bottom of the stream and add it a bit at a time, but the way the zip/gzip streams are imple,ented as subclasses of the deflator streams rather than as containers causes issues with that (if you only implement the async methds of the base class, async calls on the subclasses go through to those and miss the archive specific pieces). So, bit more of an all-in change there.
However, as a starter - I adapted a few on the unit tests to use async stream calls as a test, and those changes could be made independantly of library changes (as it stands and async calls will be forwarded to the sync versions by the base stream class, but it async methods were to be implemented later that would mean there was already a test base for them).
@piksel and comments and/or objections to the idea of adding some async tests to the existing zip test suite? (would just be variants of the existing tests but with async stream calls to start with)
Running into the same issue as reported in a similar library https://github.com/haf/DotNetZip.Semverd/issues/60
Uncaught (in promise) Error: System.NotSupportedException: Synchronous reads are not supported.
at Microsoft.AspNetCore.Components.Forms.BrowserFileStream.Read(Byte[] buffer, Int32 offset, Int32 count)
at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.Fill()
at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.ReadLeByte()
at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.ReadLeShort()
at ICSharpCode.SharpZipLib.Zip.Compression.Streams.InflaterInputBuffer.ReadLeInt()
at ICSharpCode.SharpZipLib.Zip.ZipInputStream.GetNextEntry()
It's being worked on a bit at a time, but there's quite a bit of work to change everywhere.
Do we want to close this, or leave it in case of adding async support to the other stream classes (Bzip2 etc) ?
They should probably be their own issues, although much of the work done in #574 can be used to implement them in the other streams as well. full async/await pattern stream is kind of vague as a issue scope. I will leave it open for now...