(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) approach. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
