Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking in spawn_future_async's argument? #311

Closed
aweinstock314 opened this issue Apr 13, 2017 · 5 comments
Closed

Blocking in spawn_future_async's argument? #311

aweinstock314 opened this issue Apr 13, 2017 · 5 comments
Labels

Comments

@aweinstock314
Copy link

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
Copy link
Member

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

@nikomatsakis
Copy link
Member

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
Copy link
Author

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

@aweinstock314
Copy link
Author

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 cuviper added the bug label Oct 26, 2017
@cuviper
Copy link
Member

cuviper commented Feb 24, 2023

This code was removed in #716.

@cuviper cuviper closed this as not planned Won't fix, can't repro, duplicate, stale Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants