Tokio benchmark results may be significantly inaccurate

[huntc]

I believe that most benchmarking of Tokio-based usage will yield figures that are significantly incorrect. This is due to Tokio's block_on's future not being executed as a worker task. More information is here: tokio-rs/tokio#5446

Would a PR be welcome where we address this issue, perhaps by requiring Criterion's block_on to have a result with Send and then performing a spawn? Alternatively, a new block_on_worker method?

My Criterion-based benchmarks made me spend hours working out why my library was slow, when in fact it turned out to be the way I was using Tokio with block_on.

[huntc]

Closing as there doesn't appear to be any interest after two weeks.