Use async functions in sync context to avoid code duplication. #565
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 17, 2025
We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! ghstack-source-id: 296756465 Pull Request resolved: #565
meta-cla
bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 17, 2025
Pull Request resolved: #565 We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) ghstack-source-id: 296927735
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 17, 2025
Pull Request resolved: #565 We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. ghstack-source-id: 296934588 Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/)
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 18, 2025
Pull Request resolved: #565 We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. ghstack-source-id: 297091858 Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/)
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 18, 2025
Pull Request resolved: #565 We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. ghstack-source-id: 297094308 Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/)
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 18, 2025
Pull Request resolved: #565 We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. See [avoiding async code duplication] in the diff for a description of the approach. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. To indicate to the synchronous actor that it is ok to `get()` despite this setup, we temporarily blank out the running asyncio loop while a asynchronous actor is running a message. We need to eventually figure out a way to get the synchronous actors running on a thread that truly is not the asyncio event loop. ghstack-source-id: 297098923 Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/)
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
zdevito
added a commit
that referenced
this pull request
Jul 18, 2025
Pull Request resolved: #565 We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. See [avoiding async code duplication] in the diff for a description of the approach. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. To indicate to the synchronous actor that it is ok to `get()` despite this setup, we temporarily blank out the running asyncio loop while a asynchronous actor is running a message. We need to eventually figure out a way to get the synchronous actors running on a thread that truly is not the asyncio event loop. ghstack-source-id: 297182373 Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/)
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
…ion." We currently have a lot of code duplication for blocking/nonblocking variants. This PR lets the blocking variants be defined in terms of the async ones. It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually. TODO: expand writeup. Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop. Differential Revision: [D78466520](https://our.internmc.facebook.com/intern/diff/D78466520/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D78466520/)! [ghstack-poisoned]
|
This pull request was exported from Phabricator. Differential Revision: D78466520 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack (oldest at bottom):
We currently have a lot of code duplication for blocking/nonblocking variants.
This PR lets the blocking variants be defined in terms of the async ones.
It first directly exposes the tokio Future object to python, letting it choose to synchronously block on it, or turn it into a asyncio.Future. Then when we are running async code to do pipe receives in a sync context, we can skip running a real event loop and just step the coroutine manually.
TODO: expand writeup.
Currently there is jank around the fact that we are running synchronous actor code on a thread that already has a running event loop. I put in a workaround with a comment, but we should resolve this by not running the sync code on the asyncio loop.
Differential Revision: D78466520
NOTE FOR REVIEWERS: This PR has internal Meta-specific changes or comments, please review them on Phabricator!