-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
asyncio terminates unexpectedly #16569
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
Comments
To add a few observations. The problem goes away if a second task is launched that simply does a repeated async sleep. This explains why the fault only occurs in simple scripts [EDIT] see below. When the fault occurs the await evt.wait() # Should hang there is no While the example script is artificial I've encountered this bug a few times in simple scripts intended to test applications. The work-round is trivial, but the tendency for premature exit may confuse beginners. The workround was to replace the |
Also present on MicroPython v1.24.0 on ESP32 |
…lete. The issue is described in details in micropython#16759 This amended commit also fixes these issues: micropython#16569 micropython#16318 Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
The issue is described in details in micropython#16759 This amended commit also fixes these issues: micropython#16569 micropython#16318 Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
The issue is described in details in micropython#16759 This amended commit also fixes these issues: micropython#16569 micropython#16318 Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
The issue is described in details in micropython#16759 This amended commit also fixes these issues: micropython#16569 micropython#16318 Test cases have been updated to document the unauthorized use of Event.set() from soft IRQ, and to be skipped in unsupported environments (webassembly and emit native). Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
The issue is described in details in micropython#16759 This amended commit also fixes these issues: micropython#16569 micropython#16318 Test cases have been updated to document the unauthorized use of Event.set() from soft IRQ, and to be skipped in unsupported environments (webassembly and emit native). Code has been improved according to review from dpgeorge. Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
The issue is described in details in micropython#16759 This amended commit also fixes these issues: micropython#16569 micropython#16318 Test cases have been updated to document the unauthorized use of Event.set() from soft IRQ, and to be skipped in unsupported environments (webassembly and emit native). Code has been improved according to review from dpgeorge. Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
This commit fixes three open issues related to the asyncio scheduler exiting prematurely when the main task queue is empty, in cases where CPython would not exit (for example, because the main task is not done because it's on a different queue). In the first case, the scheduler exits because running a task via `run_until_complete` did not schedule any dependent tasks. In the other two cases, the scheduler exits because the tasks are queued in an event queue. Tests have been added which reproduce the original issues. These test cases document the unauthorized use of `Event.set()` from a soft IRQ, and are skipped in unsupported environments (webassembly and native emitter). Fixes issues micropython#16759, micropython#16569 and micropython#16318. Signed-off-by: Yoctopuce dev <dev@yoctopuce.com>
Fixed by bdb7e03 |
Port, board and/or hardware
Unix build (also verified on RP2 2)
MicroPython version
MicroPython v1.24.1 on 2024-11-29; Raspberry Pi Pico2 with RP2350
Reproduction
Paste the following at the REPL
Expected behaviour
Should print 1, 2, 3 then hang. This happens under CPython 3.10.12
Observed behaviour
Under MP, after expected output, it returns to the REPL.
Additional Information
This may be related to #16318
I am encountering the phenomenon of premature return in a number of situations, notably in test scripts where there are no pending tasks. I have never observed it in applications where there are multiple concurrent tasks.
Code of Conduct
Yes, I agree
The text was updated successfully, but these errors were encountered: