Reset during input() call gives EOFError and further reset/stop attempts fail to return control

[microbit-matt-hillsdon]

From microbit-foundation/python-editor-v3#1102

Reset during an input() call gives EOFError and further reset/stop attempts fail to return control so you can't restart the program in the simulator.

Minimal reproduction:

input("Name? ") # reset when prompted

Originally encountered on microbit-foundation/python-editor-v3#1102 with an input call in a while loop which is a more likely real-world reproduction.

[microbit-matt-hillsdon]

Had a quick look but only got as far as identifying the moving parts. input calls readline which can return Ctrl-D as an error code which results in input throwing EOFError. Ultimately it's calling our mp_hal_stdin_rx_chr which is a loop with sleep/background processing waiting input from JS via a ring buffer.

[microbit-matt-hillsdon]

So the cause appears to be that Ctrl-C doesn’t interrupt the program during an input call. It does in CPython.

To stop the program we send Ctrl-C, Ctrl-D to escape from user Python code to our main loop. The Ctrl-C is ignored and the Ctrl-D gives EOFError.

If you’ve already typed some characters input() appears to entirely uninterruptible as Ctrl-D does nothing in that case.

Now that we throw away all the WASM state on restart we might have more options for interrupting but perhaps this should be fixed in MicroPython too.

[microbit-matt-hillsdon]

So the cause appears to be that Ctrl-C doesn’t interrupt the program during an input call. It does in CPython.

And it does on a real device, so this is a sim-only issue.

[dpgeorge]

It works correctly on hardware: if you run input() at the REPL and press ctrl-C then it raises a KeyboardInterrupt and returns to the REPL.

[microbit-matt-hillsdon]

Yep, hardware is great. It also doesn't work here: https://micropython.org/unicorn/

[dpgeorge]

It also doesn't work here: https://micropython.org/unicorn/

Hmm, that's curious. That emulator is completely different to the microbit simulator (it runs actual ARM-compiled firmware in a qemu-based ARM emulator) so the cause is probably different.

[dpgeorge]

Try the following:

diff --git a/src/mphalport.c b/src/mphalport.c
index 266a8e5..1d2771f 100644
--- a/src/mphalport.c
+++ b/src/mphalport.c
@@ -25,6 +25,7 @@ int mp_hal_stdin_rx_chr(void) {
         if (c != -1) {
             return c;
         }
+        mp_handle_pending(true);
         microbit_hal_idle();
     }
 }

That will handle pending exceptions while waiting for characters.

[microbit-matt-hillsdon]

Thanks Damien, this is looking good. I've updated the PR. I'll play with it a little more before merging.