Skip to content

tools: Only issue a single Ctrl-C when entering raw REPL. #15991

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

Merged
merged 1 commit into from
Oct 15, 2024

Conversation

dpgeorge
Copy link
Member

Summary

A long time ago when there was only the stm port, Ctrl-C would trigger a preemptive NLR jump to break out of running code. Then in commit 124df6f a more general approach to asynchronous KeyboardInterrupt exceptions was implemented, and stmhal supported both approaches, with the general (soft) interrupt taking priority.

Then in commit bc1488a pyboard.py was updated with a corresponding change to make it issue a double Ctrl-C to break out of any existing code when entering the raw REPL (two Ctrl-C characters were sent in order to more reliably trigger the preemptive NLR jump).

No other port has preemptive NLR jumps and so a double Ctrl-C doesn't really behave any differently to a single Ctrl-C: with USB CDC the double Ctrl-C would most likely be in the same USB packet and so processed in the same low-level USB callback, so it's just setting the keyboard interrupt flag twice in a row. The VM/runtime then just sees one keyboard interrupt and acts as though only one Ctrl-C was sent.

This commit changes the double Ctrl-C to a single Ctrl-C in pyboard.py and mpremote. That keeps things as simple as they need to be.

Testing

Ran the test suite on a PYBD-SF2 and ESP32_GENERIC board. It passes.

Also ran the mpremote tests on the same hardware. They also pass.

Trade-offs and Alternatives

There's a slight risk this may change behaviour of some code which expects two Ctrl-C's, but that's unlikely because in the vast majority of cases two back-to-back Ctrl-C's will just end up being one KeyboardInterrupt, ie equivalent to a single Ctrl-C (especially due to #15988 that preemptive NLR jump is removed).

@dpgeorge dpgeorge added the tools Relates to tools/ directory in source, or other tooling label Oct 10, 2024
@dpgeorge dpgeorge requested a review from projectgus October 10, 2024 05:53
Copy link

codecov bot commented Oct 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.57%. Comparing base (7746785) to head (d92694c).
Report is 1 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #15991   +/-   ##
=======================================
  Coverage   98.57%   98.57%           
=======================================
  Files         164      164           
  Lines       21336    21336           
=======================================
  Hits        21031    21031           
  Misses        305      305           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

@dpgeorge dpgeorge added this to the release-1.24.0 milestone Oct 10, 2024
A long time ago when there was only the `stm` port, Ctrl-C would trigger a
preemptive NLR jump to break out of running code.  Then in commit
124df6f a more general approach to
asynchronous `KeyboardInterrupt` exceptions was implemented, and `stmhal`
supported both approaches, with the general (soft) interrupt taking
priority.

Then in commit bc1488a `pyboard.py` was
updated with a corresponding change to make it issue a double Ctrl-C to
break out of any existing code when entering the raw REPL (two Ctrl-C
characters were sent in order to more reliably trigger the preemptive NLR
jump).

No other port has preemptive NLR jumps and so a double Ctrl-C doesn't
really behave any differently to a single Ctrl-C: with USB CDC the double
Ctrl-C would most likely be in the same USB packet and so processed in the
same low-level USB callback, so it's just setting the keyboard interrupt
flag twice in a row.  The VM/runtime then just sees one keyboard interrupt
and acts as though only one Ctrl-C was sent.

This commit changes the double Ctrl-C to a single Ctrl-C in `pyboard.py`
and `mpremote`.  That keeps things as simple as they need to be.

Signed-off-by: Damien George <damien@micropython.org>
@dpgeorge dpgeorge force-pushed the tools-only-do-a-single-ctrl-c branch from a207d21 to d92694c Compare October 15, 2024 00:40
@dpgeorge dpgeorge merged commit d92694c into micropython:master Oct 15, 2024
63 checks passed
@dpgeorge dpgeorge deleted the tools-only-do-a-single-ctrl-c branch October 15, 2024 00:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tools Relates to tools/ directory in source, or other tooling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy