-
-
Notifications
You must be signed in to change notification settings - Fork 33.3k
Description
Bug report
Bug description:
In the current asyncio REPL, the event loop runs in the main thread, while the interactive console operates in a separate thread as both are running blocking loops. This leads to issues with console input handling, as noted in issue gh-140163 and gh-138827.
cpython/Lib/asyncio/__main__.py
Lines 226 to 240 in d86ad87
| repl_thread = REPLThread(name="Interactive thread") | |
| repl_thread.daemon = True | |
| repl_thread.start() | |
| while True: | |
| try: | |
| loop.run_forever() | |
| except KeyboardInterrupt: | |
| keyboard_interrupted = True | |
| if repl_future and not repl_future.done(): | |
| repl_future.cancel() | |
| repl_thread.interrupt() | |
| continue | |
| else: | |
| break |
While this is a MacOS-specific issue, it reveals a defect of the existing implementation. Specifically, the REPL can never receives Ctrl-C event and set the readline status properly, as it does normally. As the above code shows, the outer-most loop catches the KeyboardInterrupt and sets a flag, then tells the REPL to respond. However, the console loop never stops when this happens, because you can't actually interrupt input() from outside the thread, making it unable to respond to outer events.
So I rethink of the necessity of separate threads and also refer to the implementation of IPython. In a REPL, each cell is executed, and the result is awaited. There doesn't seem to be a need for a concurrent setup. A simple loop.run_until_complete() will do, as IPython does. At the same time, this can also greatly simplify the existing code.
However, I know I could be very wrong. So please correct me.
DPO link: https://discuss.python.org/t/consider-removing-the-thread-and-future-handling-in-asyncio-repl/104457
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
Metadata
Metadata
Assignees
Labels
Projects
Status