On 2021-12-04 Sebastian Andrzej Siewior wrote:
> On 2021-11-30 00:25:11 [+0200], Lasse Collin wrote:
> > Separate soft and hard limits might be convenient from
> > implementation point of view though. xz would need --memlimit-soft
> > (or some better name) which would always have some default value
> > (like MemAvailable). The threaded decoder in liblzma would need to
> > take two memlimit values. Then there would be no need for an enum
> > (or a flag) to specify the memlimit mode (assuming that
> > LZMA_MEMLIMIT_THREAD is removed).  
> 
> Ah I see. So one would say soft-limit 80MiB, hard-limit 2^60bytes and
> would get no threading at all / LZMA_MEMLIMIT_NO_THREAD. And with soft
> 1GiB, hard 2^60bytes would get the threading mode. (2^60 is made up
> no limit).

Yes. It's fairly simple from implementation point of view but is it
clear enough for the users, I'm not sure.

I suppose the alternative is having just one limit value and a flag to
tell if it is a soft limit (so no limit for single-threaded case) or a
hard limit (return LZMA_MEM_ERROR if too low for even single thread).
Having separate soft and hard limits instead can achieve the same and a
little more, so I think I'll choose the two-value approach and hope it's
clear enough for users.

> > I wonder if relying on the lzma_mt struct is useful for the decoder.
> > Perhaps the options could be passed directly as arguments as there
> > are still 2-3 fewer than needed for the encoder.  
> 
> Thre is
> - num threads
> - flags
> - memlimit
> - timeout
> 
> One struct to rule them all and you could extend it without the need
> to change the ABI.
> I took one of the reserved ones for the memlimit. If you put the two
> memory limits and number of threads in one init/configure function
> then only flags and timeout is left. Maybe that would be enought then.

You have a valid point. Either approach works, new functions can be
added if needed for extending the ABI, but having just one can be nice
in the long term.

I was hoping to get this finished by Christmas but due to a recent sad
event, late January is my target for the next alpha release now. I hope
to include a few other things too, including some of Jia Tan's patches
(we've chatted outside the xz-devel list). Thank you for understanding.

-- 
Lasse Collin

Reply via email to