Repository navigation
Should we have a way to let some other coroutine runner take temporary control of a task? #649
Description
So there's a cute hack, which as far as I know @agronholm was the first to discover, where you can use an async with block to temporarily switch between coroutine runners. For example:
async def somefunc():
await do_something_in_main_thread()
async with in_worker_thread():
do_something_blocking()
await do_something_in_main_thread()Another possible application would be to allow trio-asyncio to switch back and forth between trio mode and asyncio mode within a single function.
This is kind of brain melting, but the implementation is surprisingly simple: a task's current execution is represented by a coroutine object. So, you suspend the coroutine, and from Trio's point of view it becomes "blocked"; then you take that coroutine object and give it to another coroutine runner to iterate for a while. Later, it gets handed back and Trio "resumes" it.
You can't actually implement something like this right now though, using Trio's public API. You can suspend a task, and get the coroutine object... but the coroutine is suspended inside wait_task_rescheduled, so to resume you need to send in the kind of value that wait_task_rescheduled is expecting, and that's not part of the public API. Similarly, to resume a task, trio.hazmat.reschedule will send in some kind of value, but you're not supposed to know how to interpret it – only wait_task_rescheduled knows that, so to resume the task you have to somehow get back into wait_task_rescheduled.
But it wouldn't be terribly hard to add a new suspend/resume API just for this. In trio.hazmat, obviously! This is extremely hazmat-y. But that's why trio.hazmat exists, so we can expose hazmat-y things. Something like:
@types.coroutine
def detach_task(abort_fn):
yield some_magic_value(abort_fn)
@types.coroutine
def reattach_task(yield_value):
got = yield yield_value
do_whatever_wait_task_rescheduled_would_do_with(got)So the idea is that to detach the task from trio, you do await detach_task(abort_fn), which is exactly like wait_task_rescheduled except that it has a documented API for what you send into it to resume the task (maybe None, or maybe it's return yield ..., so whoever resumes the coroutine can choose the return value). And then you iterate the coroutine however you want, in whatever context you want – as a synchronous thread, as an asyncio Task, whatever. And then, when you're finished, you do await reattach_task(yield_value), and it sends that yield_value to the coroutine runner – so for asyncio maybe it's a special Future, whatever you like, nothing to do with trio really, just make sure that your other coroutine runner stops trying to mess with this coroutine objects – and then it goes into a state where you can call trio.hazmat.reschedule and continue.
I think this + #642 would make it possible to fully implement curio's "async threads" API as a trio library.
So... is it a good idea?
I've known about this trick for quite some time, and hesitated because async with in_worker_thread seemed so magical that it was in dubious taste. But... OTOH trio's lowest-level APIs do try hard to make anything possible, regardless of whether I think it's in good taste or not :-). And using this in trio-asyncio seems like it might be compelling? And the API described above is would not be too terrible to implement or maintain. (That's the other thing... I haven't been excited about this because I couldn't figure out how to even do it while respecting trio's abstraction boundaries. But then today I figured out the API above.)
Activity
m-u-xyz commentedon Sep 6, 2018
That's kind of brain-melting and we'd need to have a hard look at how to do hook this into
trio_asyncio, but, yeah, IMHO this would be cool to have.We also need to figure out how to do the same thing in reverse.
njsmith commentedon Sep 6, 2018
Doing the handoff part in reverse is fairly straightforward, I think, because asyncio's yield protocol is effectively public (IIRC:
yieldaFuture, sendNonewhen the future is done). Probably some details to work out around making trio task bookkeeping and asyncio task bookkeeping line up – this applies in both directions I guess. Like:I'm not sure how much this matters, but as we've seen with aiohttp, asyncio code does sometimes make strong assumptions about
asyncio.current_task().m-u-xyz commentedon Sep 6, 2018
Hmm. I was thinking more of
async with trio_modewhich would need to somehow set up a Trio task to run the Trio part of the coroutine in.NB: your assertions will fail: you cannot re-purpose the original "outer" task, because there may be more than one concurrent "inner" task. So you need a new one. For the same reason you'll probably need a new context manager for each level, so
async with trio_mode()etc.njsmith commentedon Sep 6, 2018
Yeah, it'd have to spawn it under the loop's nursery. I guess teardown might be an issue – like maybe we also need a way to say "don't just detach this task temporarily, actually forget about it entirely, pretend it just exited even though the coroutine wasn't exhausted". We need to prototype some stuff here to learn what the actual tricky bits are :-).
I don't understand. I'm imagining that this is all within the text of a single function, and by definition a single Python function is a purely sequential thing, no concurrency allowed.
I'm just being lazy with my pseudocode :-). No point in worrying about details like parentheses when we don't even know if the basic idea is possible or useful :-).
m-u-xyz commentedon Sep 6, 2018
Yeah, in your example it's all within a single function, but conceptually it's the same as
and nothing prevents one from inserting a couple of nurseries and
start_soons /ensure_futures in there. I'd rather avoid the thorniness that creeps in when we try to special-case the question whether there is (or is not) an outer trio and/or asyncio task we could temporarily re-purpose to run theasync withcontext. Best to always allocate a new temporary task, methinks.njsmith commentedon Sep 7, 2018
I was imagining that we'd keep some kind of bidirectional mapping between asyncio and trio
Tasks, so that a transition from a given aioTaskalways give you the same trioTask, and vice-versa. That's well-defined even in your complex cases. I'm not sure it's actually important though. And there's a thorny problem of figuring out when aTaskis no longer needed.Support handing off coroutines between Trio and other runners
Support handing off coroutines between Trio and other runners