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

Added future::on_poll, future::on_poll_pending and future::on_poll_ready #2842

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kulst
Copy link

@kulst kulst commented Mar 16, 2024

This pull request adds the possibility to create wrapped futures that additionally invoke a function when they get polled. The function has mutable access to the Context and the returning Poll of the wrapped future.

I can imagine several possible use cases for that:

  • Call the waker of a future that would not be woken otherwise
  • Let the application know each time a future's poll returns (e.g. for logging)
  • Abort a future after a specific number of pending polls

The futures are created by three free functions. Examples are given in the code comments.

Comments would be really appreciated as

  • this is my first pull request and I am not entirely sure if a feature like this is in scope of the project
  • the futures could also be created by extending the FutureExt trait with additional methods
  • the OnPoll, OnPollPending and OnPollReady structs could also be realized as generic structs

@kulst kulst marked this pull request as draft March 16, 2024 11:11
@kulst kulst marked this pull request as ready for review March 16, 2024 11:31
@taiki-e
Copy link
Member

taiki-e commented Mar 16, 2024

Thanks for the PR. We recently received another PR similar to this one (#2840 by @coolreader18). (Although this PR is 3 futures with a post-called function in different conditions, and #2840 is a future with a pre-polled future, so it's not like either one covers the other.)

To be honest, I don't want to accept all of these kinds of similar and slightly different APIs, none of them seem that common, and they seem easy to implement locally.

If any particular one is widely used, I would prefer to accept it, but if not, I would tend to close both for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants