Blocking in `spawn_future_async`'s argument?

[aweinstock314]

The documentation for spawn_future_async says that the future it's passed is run in rayon's thread pool, and the returned future polls for the result. I had assumed that means that the intended use is to do number crunching/blocking operations inside the passed future, and polling the returned RayonFuture (e.g. in a tokio reactor) wouldn't block.

This is inconsistent with experimentation. Distilled example: https://github.com/aweinstock314/power/blob/master/examples/rayon_test.rs, full context of what I was trying to do: https://github.com/aweinstock314/power/blob/354921a2b37d5c28d9ec02e26746d1f9e6e4632a/src/main.rs#L200-L234

The workaround of combining rayon::spawn_async and futures::sync::oneshot::channel has the semantics that I hoped to get from spawn_future_async. I'm not sure if this is a documentation bug or an implementation bug.

[nikomatsakis]

Hmm, that seems surprising. I would not expect poll to block. Could well be a bug!

[nikomatsakis]

Looking at your example, my guess is that the problem actually has to do with cancellation, and not true blocking. In particular, if the "slow" future happens to be cancelled before it has actually started, you will be ok. But once it starts, it won't be asynchronously interrupted, and hence it will run to completion.

But I'm not sure then why the "working example" doesn't encounter a problem.

I'll try to give this a spin locally (I guess that test case is standalone? looks that way.)

[aweinstock314]

Yes, the test case is standalone (modulo Cargo.toml).

[aweinstock314]

As for why I expected it to work: my expectation was that futures::future::lazy(move || { Ok(expensive_work()) })'s poll is running in rayon's threadpool (and is expected to block in expensive_work()), but slow's poll (and by composition slow.select(fast)'s poll) should just be checking for some kind of communication (e.g. futures::sync::oneshot) and should't block (which would be bad since it's running in tokio's event loop).

[cuviper]

This code was removed in #716.