-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
timer: sleep
future should become !Unpin
#3028
Comments
Be aware that it is very commonly used in manual |
You think that adding |
If we keep it as a named type rather than an |
Is there a reason for it to stay a named type of boxing it is an acceptable strategy? We can document the pattern. |
If it stays named, boxing is not forced since they can use pin-project. |
I am interested in picking that up if it is fine. If so, a bit of guidance will be highly appreciated. |
It should just require the addition of a |
I figured that much. My question was more around the transition to using intrusive list for the timer. |
This would be a breaking change and we haven't forked off for 1.0 yet. I also believe @bdonlan is exploring a bigger timer change right now. |
I see, that makes sense |
For 1.0, I would be inclined to have an API that looks a bit like this:
The reason to do this this way is that it may be possible to avoid boxing even for unpinned timers in some cases. In particular, we can have a single per-task timer that tracks the earliest timeout seen the last time the task was polled. This would allow us to avoid allocation or pinning provided that the timer is polled on a tokio reactor thread (of course, if polled outside the reactor, we must actually create a timer object that we register with whatever reactor it was created on). |
Upon further thought, avoiding timer state (by associating wakeup times with the task) would require changes in As for the intrusive list changes, I'm actively working on them at the moment. |
This is more-or-less a half-rewrite of the current time driver, supporting the use of intrusive futures for timer registration. Fixes: tokio-rs#3028, tokio-rs#3069
## Issue Addressed resolves #2129 resolves #2099 addresses some of #1712 unblocks #2076 unblocks #2153 ## Proposed Changes - Updates all the dependencies mentioned in #2129, except for web3. They haven't merged their tokio 1.0 update because they are waiting on some dependencies of their own. Since we only use web3 in tests, I think updating it in a separate issue is fine. If they are able to merge soon though, I can update in this PR. - Updates `tokio_util` to 0.6.2 and `bytes` to 1.0.1. - We haven't made a discv5 release since merging tokio 1.0 updates so I'm using a commit rather than release atm. **Edit:** I think we should merge an update of `tokio_util` to 0.6.2 into discv5 before this release because it has panic fixes in `DelayQueue` --> PR in discv5: sigp/discv5#58 ## Additional Info tokio 1.0 changes that required some changes in lighthouse: - `interval.next().await.is_some()` -> `interval.tick().await` - `sleep` future is now `!Unpin` -> tokio-rs/tokio#3028 - `try_recv` has been temporarily removed from `mpsc` -> tokio-rs/tokio#3350 - stream features have moved to `tokio-stream` and `broadcast::Receiver::into_stream()` has been temporarily removed -> `tokio-rs/tokio#2870 - I've copied over the `BroadcastStream` wrapper from this PR, but can update to use `tokio-stream` once it's merged tokio-rs/tokio#3384 Co-authored-by: realbigsean <seananderson33@gmail.com>
This would allow using an intrusive-list for the timer.
The text was updated successfully, but these errors were encountered: