Hi Christoph, hi Dave, hi all --

"Processor preemptedProcess" does not behave as it used to be. It now answers the current ui process even if CMD+Dot interrupts the "[ [] repeat ] fork" from the interrupt watcher.

Maybe you can spot the issue right away?

ProcessorScheduler >> preemptedProcess
"Return the process that the currently active process just preempted."
self activeProcess priority to: 1 by: -1 do: [:priority |
(quiescentProcessLists at: priority) ifNotEmpty: [:list |
^ Smalltalk processPreemptionYields
ifTrue: [list last]
ifFalse: [list first]]].
^ nil

Best,
Marcel
Am 16.12.2021 14:33:51 schrieb David T. Lewis <lewis at mail.msen.com>:
On Thu, Dec 16, 2021 at 11:27:09AM +0100, Marcel Taeumel wrote:
> Hi all --
>
> I am investigating a?? regression revealed via DebuggerTests >> test01UserInterrupt. One cannot interrupt "[ [] repeat ] fork" from a do-it anymore. :-(
>
> VM: 202112022203 (32-bit, Windows 10)
>
> Update: #20872
>
> 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".
>

Confirming on Linux and also on an interpreter VM with trunk level V3 image,
so the issue is in the image, not the VM.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211216/8d12424c/attachment.html>