Code changes

• Use std::panic to propagate panics from the thread pool into the async context, rather than triggering the Rayon panic handler.
• Add AsyncRayonHandle type that implements Future, which makes the async-trait crate unnecessary.
• Bypass Tokio RecvError. We control the Sender, so it should never be dropped too early.
• Remove prelude module.
• Seal AsyncThreadPool trait.

Repository changes

• Update CI settings to support Rust 1.45.0 and up.
• Update Codecov settings.
• Add changelog.
• Update README.

I have been working on a library that is supposed to make it easier to work with blocking code while writing async programs: https://docs.rs/impedance/0.3.0/impedance/

One such module in this library is the rayon one. Currently, this provides a function that lets you correctly use a 'static rayon ParallelIterator in an asynchronous fashion: https://docs.rs/impedance/0.3.0/impedance/rayon/fn.par_iter.html

This code is very similar to the way tokio-rayon works (as they both use the suggestion from the tokio readme itself: use a oneshot), but with one difference: impedance catches panic's and allows users to unpack and resume unwinds.

Today, I was looking into adding a more complete api to impedance that lets users easily use rayon ParallelIterators that contain references (https://github.com/guswynn/impedance/blob/setup/src/rayon.rs#L50-L57), but I hit a snag: https://github.com/rust-lang/rust/issues/70263#issuecomment-869913178 that may not be easy to resolve. Therefore, I an interested in offering a more general api that would be the same as tokio_rayon::spawn, except catching panics. This would let users write things like:

spawn(
     vec,
    |v| v.par_iter(|reference| ...).collect(),
)

My understanding is that the MIT licenses on our projects are very permissive so this shouldn't be a licensing problem, but I wanted to let you know of the similarities between your crate and this (planned) section of my crate and see if you have any objections to me offering such an api. Also, if tokio-rayon in the future exports an API that exposes panics to the caller, then it might be possible to have impedance just re-export, and that may be something I am interested in!