> This:
>
> diff --git a/src/liblzma/common/stream_decoder_mt.c
> b/src/liblzma/common/stream_decoder_mt.c
> --- a/src/liblzma/common/stream_decoder_mt.c
> +++ b/src/liblzma/common/stream_decoder_mt.c
> @@ -786,7 +786,7 @@ read_output_and_wait(struct lzma_stream_coder *coder,
> if (mythread_cond_timedwait(&coder->cond,
> &coder->mutex,
> wait_abs) != 0) {
> - ret = LZMA_TIMED_OUT;
> + ret = LZMA_OK;
> break;
> }
> } else {
>
> Should "fixes" it. At some point the main thread needs to check if the
> next thread is able to make progress or not and then return LZMA_OK so
> that the upper layer can figure out that no progress is made. Otherwise
> it stucks in the LZMA_TIMED_OUT loop.
This fixes it just for xz, but if no timeout is specified it will
still deadlock.
I haven't looked at the code enough to understand how to fix it for both,
but I will start to look into that.
> > The issue is with updating the memlimit with lzma_memlimit_set. As you
> > note in your comment in stream_decoder_mt_memconfig there is no way to
> > update memlimit_threading. If the memlimit_stop is set very low to
> > start, it will force memlimit_threading to be that same small value. I
> > could see users wanting to keep memlimit_threading and memlimit_stop
> > in sync or have memlimit_threading always be some function of
> > memlimit_stop (maybe memlimit_stop / 2 or something). I am not sure
> > what the best fix is for this at the moment, but I don't think having
> > only one of these values be configurable at runtime is the best idea.
> > Especially when the initialization forces memlimit_threading to be at
> > most memlimit_stop (which makes sense for almost every situation).
>
> The idea to have on limit to keep things going (no matter what) and the
> other to have reasonable limit at which point you don't want threads to
> be used.
I was following the conversation about the soft and hard memory limiting.
If a user wanted decoding to fail if it can't be done multithreaded and update
the memory limit as needed, that can't be done right now. It's a minor issue
that only matters for liblzma, but it would be nice to be able to update both
limits after decoding has started. I don't consider this a bug, more like
missing a nice to have feature. One easy solution is to add a new API
function to liblzma to update the soft memory limit for the multithreaded
decoder and do nothing / return an error on all other coders. I will add
a patch for this if you guys think it is a good idea.
Jia Tan
