Boost logo

Boost :

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
<boost_at_[hidden]> wrote:
>
> 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
> filter.

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.
>
> Jeff

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
responsive.

- Jim


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk