This project has moved and is read-only. For the latest updates, please go here.

dotnetzip used in epplus

Mar 14, 2014 at 9:49 AM
What version of dotnetzip are you using in dotnetzip new beta version?
I'm using dotnetzip version 1.9.1.8 with some programs and it has issues when using with multicore cpu.
I've used patch from:
https://dotnetzip.codeplex.com/workitem/14087
and now it works ok.
that patch changes zlib\ParallelDeflateOutputStream.cs
funcion private void EmitPendingBuffers(bool doAll, bool mustWait)
at line 874 . Changes at are line 987.
substracted from patch at https://dotnetzip.codeplex.com/workitem/14087 :
rhpainte wrote Jan 6, 2012 at 7:30 PM
The issue is reproducable anytime you are compressing data that fits into an integeral number of internal buffers inside ParallelDeflateOutputStream (The default size is set to 64KB). When it has finished loading your data into the buffers Close is called which will result in _Flush(true) being called. Since we have an integeral size _currentlyFilling is equal to -1 and we go directly to EmitPendingBuffers(true, false) and _FlushFinish().

Inside EmitPendingBuffers the outside do{} while (doAll && (_lastWritten != _latestCompressed)) can exit prematurely as it doesn't take into account number of buffers filled, as our threads could still be busy computing blocks 3-15 with _lastWritten and _latestCompressed both equalling 2.

Workround:
The suggestion by Mike is great
Modify the buffer size so that it is not nicely aligned with your file size
Fix:
Zlib\ParallelDeflateOutputStream.cs

line 987:
change
} while (doAll && (_lastWritten != _latestCompressed));
to
} while (doAll && (_lastWritten != _latestCompressed || _lastWritten != _lastFilled));
Regards,

David.
Mar 18, 2014 at 8:08 PM
Hi,
I synced the code from Dotnet zip a few weeks ago, but I cant see this fix. I'll try to add it to the next build.
Thanks Jan