From: James E. King III (jking_at_[hidden])
Date: 2019-05-22 20:50:01
On Wed, May 22, 2019 at 12:19 PM Jeff Bonyun via Boost
> I've implemented a multithreaded update to iostreams' lzma filter for my
> own purposes, and I was wondering if this change would be considered for
> including in Boost.iostreams?
Yes this sounds like an improvement. How will we detect whether
liblzma is capable? If it is not capable but specified, will we allow
the compression anyway?
> It uses liblzma's own multithreaded functions, so the changes to boost
> are actually pretty minimal. It does add a new member to the
> boost-provided lzma options struct -- to specify your desired number of
> threads -- which changes how people might use the constructor for the
Is there also an option to have it use the number of cores the
operating system is advertising?
> My two biggest concerns with including it in Boost.iostreams are:
> - Making the filter constructor backwards compatible. Right now,
> users can initialize the options struct with a single unbraced int when
> calling the filter constructor. With the change to the struct, I want to
> make sure this old way still works. I.e. not requiring a braced
> initializer list if you only want to provide the compression level.
> - Handling older versions of liblzma that didn't offer
> multithreading. I'll work on identifying the exact versions needed, and
> branching on their #defined version numbers.
> If there is appetite for it, I can make a pull request on github.
That's the best way to get started. Be sure to include tests that exercise it.
> As this would be my first submission to boost, I'm sure I'll screw
> something up and need correcting, so be patient.
I'm one of the community maintainers and iostreams is part of that
collection, so bear with us as well if we're not immediately
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk