On 2022-03-17 Jia Tan wrote:
> I attached two patches to this message. The first should fix a bug
> with the timeouts.
Thanks! This and the deadlock are now fixed (I committed them a few days
ago).
> The second patch is for the memlimit_threading update. I added a new
> API function that will fail for anything that is not the multithreaded
> decoder.
I need to consider this a little later. Some of the things I will do
next (some already have a patch on this list):
- Add fail-fast flag to lzma_stream_decoder_mt().
- Possibly fix a corner case in threaded coder if lzma_code() is
called in a similar way as in zpipe.c in in
<https://zlib.net/zlib_how.html>. That is, currently it doesn't
work but it can be made to work, I think. Supporting it makes
threaded decoder a little easier to adapt to existing apps if they
use that kind of decoding loop.
- --memlmit-threading, I wrote this weeks ago except a few details
that need to be decided. For example, I guess -M should set
--memlimit-threading just like it sets --memlimit-compress and
--memlimit-decompress.
- Initial version of automatic memlimit with --threads=0. First
version can be based on lzma_physmem() but other methods can be
added. Sebastian's patch uses MemAvailable on Linux, your patch
uses freemem from sysinfo() which equals MemFree in /proc/meminfo.
I suppose MemAvailable is a better starting point.
- Support for forcing single/multi-threaded mode with --threads for
cases when xz decides to use only one thread.
- Fix changing memlimit after LZMA_MEMLIMIT_ERROR in the old
single-threaded decoder. (I knew it's a rare use case but clearly
it's not a use case at all since I haven't seen bug reports.)
- Your test framework patches
I suppose then the next alpha release is close to ready.
--
Lasse Collin
