Re: [iostreams] Interest in multithreaded lzma filter?

From: Jeff Bonyun (jeff_at_[hidden])
Date: 2019-05-24 15:42:30

>> So basically if someone has an older lzma they are limited to boost
>> 1.70.0 or earlier.  That's perhaps reasonable as long as it is
>> documented, but it hasn't been the typical way I have seen things
>> added to existing code.
> Well, my second question was if you are confident that 1.70 does actually
> work with liblzma versions older than 5.1.1? If this isn't tested, it is not
> supported and if it is not supported it imho makes little sense to complicate
> the source code to achieve potential compatibility with (what I assume to be)
>   a very, very small number of setups.

I will be testing, with and without my additions, with every numbered 
version of liblzma before making my pull request. So I'll be able to 
answer that soon. But that doesn't deal with your real concern: that 
testing will not be automated and ongoing, and it could mysteriously 
break in the future.

My production systems are RHEL 6. They have a 4.x version of liblzma 
installed by the package manager, which is incompatible with the changes 
I am making. I get that RHEL 6 is old, but some industries have to deal 
with that sort of thing.

> However, as long as the interface is untouched by this macro I guess it would
> be fine.

The design I have right now would leave the interface the same between 
the macro on and the macro off. I.e. both would have a new "threads" 
argument and member. The macro would be used only in the cpp file. 
Working code would work in all cases. Requests for different numbers of 
threads would just be ignored if it isn't supported.

The deeper questions here are above my pay grade. I will bend to the 
whims of those with more experience maintaining boost.