-
Notifications
You must be signed in to change notification settings - Fork 653
futures_util: Add a poll_future
function
#2173
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
Comments
That function would only allow you to poll the Future one time. What is the use case for that? |
Usage example: https://github.com/YZITE/encsess2/blob/ca0d4e961289328a2ac08acd0fc2f19dc4acd453/lib/src/packet_stream.rs The most common use is either: as syntactic sugar for implementing Another usage example is: https://github.com/stjepang/smol/blob/master/src/async_io.rs |
Thus, the general use case is: avoiding code duplication and sometimes easier readable code. |
This rule also applied recursively to all futures that |
Yes, thats right. I have worked a bit with it and noticed that it probably is a rather niche and low-level functionality. It also seems to have a noticable size + performance overhead compared to implementing a |
I have not investigated the exact cause, but performance issues may be related to that a new future being created, moved, and destructed each time polled. FYI @stjepang |
original issue: smol-rs/smol#157
This function is really useful in providing a bridge between simple
async
functions andpoll_*
methods; but appropriate documentation would need to be added, because it has the limitation that all state of theFuture
, which is only saved in theFuture
itself, and not via&mut
bindings / etc., is lost after each yield, and theasync
fn should be designed to handle that case (e.g. be reentrant without strict dependency on local state; caching is ok, but external state shouldn't be corrupted if theFuture
yields and resets).The text was updated successfully, but these errors were encountered: