[squeak-dev] Regression | Cannot interrupt "[  repeat ] fork" anymore
marcel.taeumel at hpi.de
Fri Dec 17 09:07:57 UTC 2021
Hi all --
It is still not working. And it got worse. I cannot even interrupt " repeat" anymore. I tried both values for #processPreemptionYields. Still investigating.
Am 17.12.2021 09:21:06 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Christoph --
>> even if CMD+Dot interrupts the "[  repeat ] fork" from the interrupt watcher
> How did you achieve to do this? The interrupt doesn't work for me in this situation.
In EventSensor >> #userInterruptWatcher, I added something to write to stdout. Since this worked, I assumed that CMD+Dot does actually work but the wrong process gets interrupted. So I ended up in Project >> #interruptName:message:preemptedProcess: and logged the preemptedProcess. And it was the wrong one. :-)
Hi Jaromir --
> So the default processPreemptionYields value remains false, right?
Yes. The default should be cooperative scheduling within a priority level and preemptive scheduling when a higher priority gets ready (e.g., because a semaphore signaled). If you would change #processPreemptionYields to true, then cooperative scheduling cannot be designed reliably anymore. Still, you can designer a high priority process to implement, e.g., time slicing and explicitely change the order of a lower priority. Well, you can even implement priority boosts after some criteria. All that does not need to have #processPreemptionYields on true. So, yes, we keep it at "false".
Hi all --
Thanks for fixing this issue so quickly! And -- Hooray! -- the DebuggerTests actually find regresssions. :-)
Am 16.12.2021 19:29:40 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Dave, hi Marcel,
one "recent" change I noticed is that one to SmalltalkImage>>#processPreemptionYields by Dave in May, which answered false before but answers true since then. But this is just an observation, I do not know whether this change was justified by a change on the VM side.
> even if CMD+Dot interrupts the "[  repeat ] fork" from the interrupt watcher
How did you achieve to do this? The interrupt doesn't work for me in this situation.
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Donnerstag, 16. Dezember 2021 15:53:37
Betreff: Re: [squeak-dev] Regression | Cannot interrupt "[  repeat ] fork" anymore
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]]].
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev