For background, I noticed this on the rp2 port after implementing #8836, which meant that the second core spent less time doing other things and was more likely to "win" the race to clear MP_STATE_VM(sched_state), and the result was that a busy loop running on the second core prevented Ctrl-C from being delivered to a busy loop on the main core. Tracing through in gdb, the main core never got a chance to see a "pending" sched_state.

Codecov Report

Merging #8838 (9cf2e15) into master (dd77dbd) will increase coverage by 0.00%.
The diff coverage is 88.88%.

@@           Coverage Diff           @@
##           master    #8838   +/-   ##
=======================================
  Coverage   98.31%   98.31%           
=======================================
  Files         157      157           
  Lines       20342    20347    +5     
=======================================
+ Hits        19999    20004    +5     
  Misses        343      343           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dd77dbd...9cf2e15. Read the comment docs.

We are using the per-thread exception scheduling with the unix port to be able to cancel threads that are blocking on I/O. It works like this:

Suppose a thread is blocking on a syscall like read and we want to stop this thread. To do this, we call pthread_kill() to interrupt the syscall on this specific thread. However, MicroPython will automatically retry syscalls like read when interrupted (PEP 475). So to prevent the retry, we schedule a SystemExit exception on this thread before raising the signal to interrupt the syscall. Then when the syscall is interrupted, the pending exception is raised on this thread instead of retrying the syscall. This allows context managers and finally statements to properly clean up the thread that was canceled.

Making pending exceptions only occur on the main thread would break our code, so I hope we can come up with a different solution.

For example, could we make it so that the scheduler only runs on the main thread? This is inline with how CPython does things (i.e. Py_AddPendingCall). And it seems to me like it would be beneficial at least in the case where there is an unhandled exception in a scheduled callback. If the scheduler can run on any thread, and there is an unhandled exception in a scheduled callback, then it will just crash the random thread where it ran and the rest of the program will keep running in a bad state. But if all scheduled callbacks only run on the main thread and there is an unhandled exception, then the entire program crashes instead of continuing to run in a bad state. This seems like a more desirable behavior.

We are using the per-thread exception scheduling with the unix port to be able to cancel threads that are blocking on I/O.

@dlech OK thank you for the explanation! I wondered if maybe this might be the case but couldn't see any discussion around this. Definitely sounds useful though so we should keep it.

The other way to solve this is to either make it possible for mp_sched_unlock to know whether any threads have pending exceptions (this seems complicated), or probably better would be to decouple the scheduler (and the MP_STATE_VM(sched_state) variable) from pending exceptions.

I also agree that it makes sense to only dispatch the scheduler on the main thread (and I very nearly did that in this PR!). I notice in your commit that you use the same method to detect the main thread. I will make a new PR to address both.

Closed in favour of #8845