allow explicit control over single-threaded vs multi-threaded

[oconnor663]

Right now there is only the top-level rayon feature, so multi-threading is all-or-nothing. It would be better to allow each caller to choose, and perhaps to provide other executors besides Rayon. We could keep the default governed by the rayon feature, or we could make the default always single-threaded, not sure yet.

This might allow us to support a flag in b3sum that controls multithreading at runtime, for example.

@pcwalton mentioned one approach here: https://twitter.com/pcwalton/status/1215349922267987970

[oconnor663]

Copying a question that just tweeted. Not sure what to do about the standalone functions:

Do you know if there's a practical way to do this for a standalone function, a la hash()? I just ran into the limitation that functions can't have default type parameters.

[oconnor663]

rust-lang/rust#36887

[oconnor663]

Rather than create duplicated versions of all the top level functions to work around this, I'm going to add a single update_with_join method to Hasher. We'll provide a SerialJoin (which most of the API uses internally by default) and a RayonJoin (gated by the rayon feature), and using the latter with update_with_join will get you multi-threading. This will make the top level functions always single-threaded, which is probably for the best.

[oconnor663]

I just pushed fc219f4, implementing the update_with_join idea described above. I'm going to close this for now, but we can reopen it as we get more experience with the API discover any problems.

[oconnor663]

I just filed an issue with rust-lang/rust over the test failures above. rust-lang/rust#68905

[oconnor663]

update_with_join just shipped as part of version 0.2.0.