-
Notifications
You must be signed in to change notification settings - Fork 12
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
Running asyncio actors using "guest mode" vs. anyio task groups #120
Labels
discussion
enhancement
New feature or request
experiment
Exploratory design and testing
question
Further information is requested
Comments
goodboy
added
enhancement
New feature or request
question
Further information is requested
discussion
experiment
Exploratory design and testing
labels
Jun 23, 2020
Oh, another thing to keep an eye on is how this all relates with #117 and getting sane subproc spawning working. |
goodboy
added a commit
that referenced
this issue
Jun 28, 2020
This is an initial solution for #120. Allow spawning `asyncio` based actors which run `trio` in guest mode. This enables spawning `tractor` actors on top of the `asyncio` event loop whilst still leveraging the SC focused internal actor supervision machinery. Add a `tractor.to_syncio.run()` api to allow spawning tasks on the `asyncio` loop from an embedded (remote) `trio` task and return or stream results all the way back through the `tractor` IPC system using a very similar api to portals. One outstanding problem is getting SC around calls to `asyncio.create_task()`. Currently a task that crashes isn't able to easily relay the error to the embedded `trio` task without us fully enforcing the portals based message protocol (which seems superfluous given the error ref is in process). Further experiments using `anyio` task groups may alleviate this.
goodboy
added a commit
that referenced
this issue
Jun 29, 2020
This is an initial solution for #120. Allow spawning `asyncio` based actors which run `trio` in guest mode. This enables spawning `tractor` actors on top of the `asyncio` event loop whilst still leveraging the SC focused internal actor supervision machinery. Add a `tractor.to_syncio.run()` api to allow spawning tasks on the `asyncio` loop from an embedded (remote) `trio` task and return or stream results all the way back through the `tractor` IPC system using a very similar api to portals. One outstanding problem is getting SC around calls to `asyncio.create_task()`. Currently a task that crashes isn't able to easily relay the error to the embedded `trio` task without us fully enforcing the portals based message protocol (which seems superfluous given the error ref is in process). Further experiments using `anyio` task groups may alleviate this.
goodboy
added a commit
that referenced
this issue
Jun 29, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Jul 24, 2020
This is an initial solution for #120. Allow spawning `asyncio` based actors which run `trio` in guest mode. This enables spawning `tractor` actors on top of the `asyncio` event loop whilst still leveraging the SC focused internal actor supervision machinery. Add a `tractor.to_syncio.run()` api to allow spawning tasks on the `asyncio` loop from an embedded (remote) `trio` task and return or stream results all the way back through the `tractor` IPC system using a very similar api to portals. One outstanding problem is getting SC around calls to `asyncio.create_task()`. Currently a task that crashes isn't able to easily relay the error to the embedded `trio` task without us fully enforcing the portals based message protocol (which seems superfluous given the error ref is in process). Further experiments using `anyio` task groups may alleviate this.
goodboy
added a commit
that referenced
this issue
Jul 26, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Jul 27, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Jul 30, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Jul 30, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 4, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 4, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 13, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 12, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 24, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 5, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 7, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 14, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 14, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 16, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Nov 16, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 11, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 12, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 19, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 22, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 23, 2020
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Jul 5, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Jul 28, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 1, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 8, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 10, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Aug 24, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 1, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 3, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 8, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 18, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Sep 18, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 8, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 23, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Oct 28, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Nov 1, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Nov 4, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Nov 9, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Nov 30, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 3, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 7, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 8, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 10, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 12, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 15, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 15, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 15, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 16, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 17, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 17, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
goodboy
added a commit
that referenced
this issue
Dec 17, 2021
This should mostly maintain top level SC principles for any task spawned using `tractor.to_asyncio.run()`. When the `asyncio` task completes make sure to cancel the pertaining `trio` cancel scope and raise any error that may have resulted. Resolves #120
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
discussion
enhancement
New feature or request
experiment
Exploratory design and testing
question
Further information is requested
trio
recently added "guest mode" a very brilliant solution to integration with foreign event loops and we've used it with great success inpiker
for charting withQt
.I'm wondering if it's sensible to create a new actor entry point that could be run using an explicit
Nursery.start_aio_actor()
? Inpiker
there is a need for something like this being built-in to avoid hoop jumping withtrio-asyncio
. Guest mode makes a lot of sense sincetractor
machinery can pretty much run unmodified and can stay written intrio
despite being run "on top of" anasyncio
loop.The main comparison is whether to do this versus trying to make
anyio
"work".using guest mode
asyncio
will likely be done over queues/channels such as in the primary guest mode exampleasyncio
anyio
(see below)uvloop
should be supported (something we don't get withtrio-asyncio
)asyncio
specific "wrapping")asyncio
async function entry points may need to be decorated such that the correcttractor
entry point can be configured at import timeadopting
anyio
anyio
's task groups, and generally, theanyio
compat apistractor
was to encourage and motivate use oftrio
(which ideally gets us things like rust loop speedups in the core 😉)curio
support?asyncio
may end up adopting SC concepts and apis natively at which pointanyio
may be come somewhat superfluous given that guest mode exists?I'd appreciate input from others. I'm likely going to experiment with a guest mode shim in
piker
for now and see if I run into anything dangerous 🏄The text was updated successfully, but these errors were encountered: