How is this different from futures::executor::block_on ?
Closed this issue · 4 comments
The functionality provided by this crate is identical to futures::executor::block_on .
I have the following natural questions that I feel deserve to be mentioned in the readme:
What are the differences between the two versions?
If I already depend on futures with the executor feature, is there any reason to prefer pollster over futures?
If pollster is preferred in that case, why isn't the futures version implemented through pollster?
I'm aware that the readme broaches this topic to some degree t but I feel that the futures crate version deserves special mention because it is not (?) a heavy weight executor part of a larger async framework.
What are the differences between the two versions?
Practically there are no differences between the two implementations. They both use a thread parker/unparker pair as a waker to poll a future until it's completed.
If I already depend on
futureswith theexecutorfeature, is there any reason to prefer pollster over futures?
No, pollster primarily exists to provide a way to poll futures to completion in an environment that otherwise does not use a reactor.
If pollster is preferred in that case, why isn't the futures version implemented through pollster?
The futures implementation predates pollster. In addition the futures crate already has a substantial number of dependencies and adding one more is probably something that they'd like to avoid.
Yep, this is a good summary.
futures is a great crate and has a lot to give. If you're already depending on futures, then futures::executor::block_on is just fine. pollster is for applications that don't otherwise care to engage in async work.
A good example of this use-case is 3D games that use wgpu. The Adapter::request_device function, which needs to be executed to access all interesting crate functionality, is asynchronous but most applications don't care to do anything other than waiting in-place until the Adapter is ready.
Thanks for your explanations. I feel it makes sense to have this in the Readme too but feel free to close the issue in any case.