-
-
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
rt: add Handle::block_on #3569
rt: add Handle::block_on #3569
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments here.
Generally I dont think attempting an op on a shutdown runtime should panic. Instead Err is better. That said... sleep is an interesting case because it does not return Result. |
Summary from discussions on Discord:
|
@davidpdrsn what's the status of this? I think it was blocked on shutting down the timer properly. Is that issue tracked somewhere? |
@carllerche I haven't had more time to work in it. Will spend some time on it this week. |
3a8f1e4
to
d85ea74
Compare
I've pushed a bunch more changes. I think all the requirements should have tests and be working. Still missing docs but I'll work on that if people think the implementation looks sound. |
let err = Handle::current().block_on(listener.accept()).unwrap_err(); | ||
|
||
assert_eq!(err.kind(), std::io::ErrorKind::Other); | ||
assert_eq!(err.get_ref().unwrap().to_string(), "reactor gone"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error message was already there. I think it makes sense to change it to A Tokio 1.x context was found, but it is being shutdown.
for consistency. Wondering if that would be breaking change though.
99823ef
to
048bc21
Compare
We need to slow down here. Anything that touches I/O shutdown needs to factor in #3481 or it will be racy. I will try to provide a deeper review shortly. |
Thanks for the detailed tests. I am going to spend more time with this PR and will comment asap. |
Sigh, I'm sorry, it seems like this PR is exposing more bugs in shutdown 😬 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. I left some notes inline.
This is definitely a bit of a tangled problem that you are tackling. The issue is that there are known bugs with the shutdown process that you are hitting when trying to write tests. I love that you took the initiative to try to fix I/O shutdown as part of this PR. Unfortunately, the proposed solution will be racy when concurrently shutting down and registering a new resource. Issue #3481 includes a proposed solution that should avoid races.
Fixing I/O shutdown is out of scope of this PR, but you also wrote great tests that won't pass until the shutdown bugs are fixed. I see two paths forward.
a) We pause this PR until #3481 is fixed, then rebase and land this one.
b) We mark tests that cannot pass until #3481 is fixed with #[ignore]
and reference the issue. Then we revert the is_shutdown: AtomicBool
part of this PR and land it w/ known issues.
If I had to pick one, I would opt for b
as we do need Handle::block_on
and the shutdown bugs are unrelated. Thoughts?
I think I agree that b is the right path forward — we don't expect this to introduce additional broken behavior, and we believe (I think) that we'd still want the same public API once we fix #3481. |
See tokio-rs#3569 (review) for more details
See tokio-rs#3569 (review) for more details
db1acca
to
4a5bdfa
Compare
Maybe interesting data point: we've been running this in production on all our servers for 2 days. |
Co-authored-by: Carl Lerche <me@carllerche.com>
Co-authored-by: Alice Ryhl <alice@ryhl.io>
Carl has already approved this as per discussion in Discord.
This is a continuation of #3549 but with tests for the behavior described here and part of the implementation.
Still missing network operations failing if runtime associated with the handle has been shutdown. Changes to make timers and filesystem operations fail are at least passing the tests.
This is my first contribution to Tokio but let me know if I'm on the right track here 😊
Refs: #3097
Fixes #2965, #3096
cc @stuhood, @Keruspe