<div dir='auto'><div>Short notice only: This seems unrelated to the VM. I could reproduce the issue with an older VM from 2020 in WSL/Ubuntu. With a current VM and a Trunk image a few months older, the interrupt works as expected.</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto">Christoph<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Am 16.12.2021 11:27 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:10pt;font-family:'arial';color:#000000;text-align:left" dir="ltr">Hi all --<div></div><div><br></div><div>I am investigating a  regression revealed via DebuggerTests >> test01UserInterrupt. One cannot interrupt "[ [] repeat ] fork" from a do-it anymore. :-(</div><div><br></div><div><span style="font-size:13.3333px">VM: 202112022203 (32-bit, Windows 10)</span><br></div><div><span style="font-size:13.3333px">Update: #20872</span></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">Since the forked process should run at priority 40 and the "user interrupt watcher" watches at priority 60, this must work. Did we loose a process scheduling point in "[] repeat"? It's still implemented as "[self value. true] whileTrue".</span></div><div><span style="font-size:13.3333px"><br></span></div><div><span style="font-size:13.3333px">Best,</span></div><div><span style="font-size:13.3333px">Marcel</span></div></div></blockquote></div><br></div></div></div>