Repository navigation
Using asyncio in _thread #8340
Description
Hello.
This might be a feature request: asyncio is missing support for threading
import uasyncio as asyncio
import _thread
import time
async def test1(arg):
try:
while True:
print(arg)
await asyncio.sleep(1)
except Exception as e:
print('Exception in '+arg)
print(e)
def run(arg):
try:
asyncio.run(test1(arg))
except Exception as e:
print('Exception in asyncio.run ' + arg)
print(e)
print("END "+arg)
_thread.start_new_thread(run, ('core1',))
time.sleep_ms(100)
run('core0')Tested in two ports: unix with uasyncio module included and rp2 with #8310 patch
Exception within a few seconds in both ports.
Sometimes ValueError: generator already executing
Sometimes 'NoneType' object has no attribute 'ph_child'
Also I would like to create new event loop in new thread (which is automatically done in CPython). Do you think it is possible to implement proper event loop? or would there be limitations in VM? (is generator is thread safe in VM level?)
Activity
peterhinch commentedon Feb 23, 2022
You beat me to it. Give #8310 and apparently reliable two-core operation I was about to try this. I can see a definite use case for a copy of
uasynciorunning on each core.dpgeorge commentedon Feb 25, 2022
Yes this would be a good enhancement.
(Related, I've sometimes wanted to run a separate, independent uasyncio instance within a soft IRQ handler...).
dpgeorge commentedon Mar 29, 2022
Some thoughts on this:
uasyncio(which is mostly incore.py) needs to be duplicated for each core/threaduasynciofunctions to know what state they are associated withLoop, and then it might be possible to pass aloopargument around so that functions know the asyncio instance they are attached to. But this would require passingloopinto everything, including calls like.read()and.write(), and that would break all existing asyncio based codelooparound, it would need to be made implicit and the currentloopinstance instead stored in some thread-local-stateuasyncioinstances within a soft interrupt handler, that code can explicitly set theloopinstance on entry to the handler, then restore the originalloopon exitMerge pull request micropython#8340 from jepler/qstr-dependency