(Note that you need to use the same address as sender that was used to
subscribe to the list.)

On 2020-04-19 Sebastian Andrzej Siewior wrote:
> So (if I understood you correctly) what you suggest is to feed the
> liblzma API and the lib then will fire up threads based on new
> blocks. That means for a default compressed file (-6, 24MiB block
> size) each thread will allocate 24MiB as a buffer where it stores the
> output. Once the previous thread is complete, it will be able to
> save/write its data.

Yes. See how the threaded compression API works. This makes it easy for
applications to use threaded (de)compression and it works for streamed
(de)compression which is a common use case.

Note that some extra memory needs to be allocated because blocks can
finish out of order. If the code assumes that blocks finish strictly in
order, the worker threads won't be busy all the time.

With decompression one has to decide how much memory can be used by
default. If there is no limit, in the extreme case a decoder could read
the whole input file in RAM and allocate output buffer for the whole
uncompressed file. This problem doesn't exist in your mmap (or pread)

Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode

Reply via email to