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

rt: add Handle::block_on #3549

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions tokio/src/runtime/handle.rs
Original file line number Diff line number Diff line change
Expand Up @@ -201,6 +201,18 @@ impl Handle {
let _ = self.blocking_spawner.spawn(task, &self);
handle
}

/// TODO: write docs if this is a good direction
pub fn block_on<F: Future>(&self, future: F) -> F::Output {
// Enter the **runtime** context. This configures spawning, the current I/O driver, ...
let _rt_enter = self.enter();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can enter check if the runtime is still alive?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you opened a different issue, but that is someone of an orthogonal concern :)


// Enter a **blocking** context. This prevents blocking from a runtime.
let mut _blocking_enter = crate::runtime::enter(true);

// Block on the future
_blocking_enter.block_on(future).expect("failed to park thread")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then this should be a block on that runs the task and can wake up on runtime shutdown. We likely wanna use the same notify trick?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The future isn't a task per se. When the runtime is shutdown, in theory all resources should transition to a "shutdown" state and in-flight operations canceled. This would result in this block_on waking up.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if the task is doing nothing? E.g. if I just call handle.block_on(std::future::pending()), then what?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I guess my gut is that calling Handle::block_on shouldn't necessarily force exit when the runtime shuts down. My gut reaction is that handle.block_on(std::future::pending()) would just run indefinitely.

}
}

/// Error returned by `try_current` when no Runtime has been started
Expand Down