You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At this point I have to kill the process; it doesn't clean up the asyncio loop as expected on cancellation of the coroutine for the second run. If it completes within the timeout, everything is ok, and exceptions propagate as expected.
If a timeout occurs, however, while the trio.Cancelled exception is propagated (and translated to asyncio.CancelledError as expected), then it doesn't matter what exception is raised (including a re-raise of the existing one), everything hangs prior to returning to the invoking trio function.
The expectation: if the last task run in a trio_asyncio.open_loop() loop is cancelled, it should return to the main process and continue from there with the appropriate exception.
The output for the [1, 2] sequence should look something like:
Using await foo = loop.run_aio_coroutine(sleeper(timeout2)) instead of the @aio_as_trio decorator has identical behavior to the example above.
It looks like #88 may also be running into a similar issue.
Perhaps this is caused by the unusual exception base class causing a problem cleaning up the loop?
I have not tested whether async_timeout would work within the asyncio function, but it's less useful for my use case (and pulls in another dependency).
The text was updated successfully, but these errors were encountered:
Using
trio-asyncio
0.11.0 andtrio
0.16.0 (same behavior ontrio
0.15.1 also).Sample code:
The output I get:
At this point I have to kill the process; it doesn't clean up the asyncio loop as expected on cancellation of the coroutine for the second run. If it completes within the timeout, everything is ok, and exceptions propagate as expected.
If a timeout occurs, however, while the
trio.Cancelled
exception is propagated (and translated toasyncio.CancelledError
as expected), then it doesn't matter what exception is raised (including a re-raise of the existing one), everything hangs prior to returning to the invokingtrio
function.The expectation: if the last task run in a
trio_asyncio.open_loop()
loop is cancelled, it should return to the main process and continue from there with the appropriate exception.The output for the
[1, 2]
sequence should look something like:Using
await foo = loop.run_aio_coroutine(sleeper(timeout2))
instead of the@aio_as_trio
decorator has identical behavior to the example above.It looks like #88 may also be running into a similar issue.
Perhaps this is caused by the unusual exception base class causing a problem cleaning up the loop?
I have not tested whether
async_timeout
would work within theasyncio
function, but it's less useful for my use case (and pulls in another dependency).The text was updated successfully, but these errors were encountered: