Skip to content

Polymorphic Future await? #757

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

Closed
wants to merge 2 commits into from
Closed

Conversation

zdevito
Copy link
Contributor

@zdevito zdevito commented Aug 4, 2025

Stack from ghstack (oldest at bottom):

Previously if on the tokio event loop we forced our internal uses to directly await the PythonTask. This leads to a few places where we end up with a Future but want to await it from a coro alos on the tokio event loop.

We have the option of making await work in either case: on a asyncio loop createa. python future, on a tokio loop spawn/await.

If we want consumers to create Future objects themselves we probably want this. If we want tokio event loop things to be an implementation detail of monarch, we probably do not want this.

Differential Revision: D79596925

NOTE FOR REVIEWERS: This PR has internal Meta-specific changes or comments, please review them on Phabricator!

Previously if on the tokio event loop we forced our internal uses to directly await the PythonTask.  This leads to a few places where we end up with a Future but want to await it from a coro alos on the tokio event loop.

We have the option of making __await__ work in either case: on a asyncio loop createa. python future, on a tokio loop spawn/await.

If we want consumers to create Future objects themselves we probably want this. If we want tokio event loop things to be an implementation detail of monarch, we probably do not want this.

Differential Revision: [D79596925](https://our.internmc.facebook.com/intern/diff/D79596925/)

**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D79596925/)!

[ghstack-poisoned]
@meta-cla meta-cla bot added the CLA Signed This label is managed by the Meta Open Source bot. label Aug 4, 2025
zdevito added a commit that referenced this pull request Aug 4, 2025
Previously if on the tokio event loop we forced our internal uses to directly await the PythonTask.  This leads to a few places where we end up with a Future but want to await it from a coro alos on the tokio event loop.

We have the option of making __await__ work in either case: on a asyncio loop createa. python future, on a tokio loop spawn/await.

If we want consumers to create Future objects themselves we probably want this. If we want tokio event loop things to be an implementation detail of monarch, we probably do not want this.

Differential Revision: [D79596925](https://our.internmc.facebook.com/intern/diff/D79596925/)

**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D79596925/)!

ghstack-source-id: 300662990
Pull Request resolved: #757
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D79596925

Previously if on the tokio event loop we forced our internal uses to directly await the PythonTask.  This leads to a few places where we end up with a Future but want to await it from a coro alos on the tokio event loop.

We have the option of making __await__ work in either case: on a asyncio loop createa. python future, on a tokio loop spawn/await.

If we want consumers to create Future objects themselves we probably want this. If we want tokio event loop things to be an implementation detail of monarch, we probably do not want this.

Differential Revision: [D79596925](https://our.internmc.facebook.com/intern/diff/D79596925/)

**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D79596925/)!

[ghstack-poisoned]
zdevito added a commit that referenced this pull request Aug 5, 2025
Pull Request resolved: #757

Previously if on the tokio event loop we forced our internal uses to directly await the PythonTask.  This leads to a few places where we end up with a Future but want to await it from a coro also on the tokio event loop.

We have the option of making `__await__` work in either case: on a asyncio loop, create a python future, on a tokio loop spawn/await.

If we want consumers to create Future objects themselves we probably want this. If we want tokio event loop things to be an implementation detail of monarch, we probably do not want this.

Differential Revision: [D79596925](https://our.internmc.facebook.com/intern/diff/D79596925/)

**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D79596925/)!
ghstack-source-id: 300750788
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D79596925

@facebook-github-bot
Copy link
Contributor

This pull request has been merged in 694951b.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Meta Open Source bot. fb-exported Merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants