Wonderful, many thanks for your explanation; now I know what to look for! Thanks,
Jaromir

From: Marcel Taeumel<mailto:marcel.taeumel at hpi.de>
Sent: Friday, December 17, 2021 15:55
To: squeak-dev<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore

Hi Jaromir --

Here is another example. I know some projects that happily fork Morphic code because it seems easier that having to deal with #step. Now the issue is that Morphic's data structures are not thread-safe. If Morphic's main UI process cannot rely on its explicit suspension point, Morphic code running in other processes at priority 40 will more likely raise debuggers because of some instVars still being "nil" etc. We had this in the past (around 2007). Later, when #processPreemptionYields changed from "true" to "false", the issue was gone, even though Morphic's data structures are still not thread-safe per se und you still should not fork Morphic code without care. :-)

Best,
Marcel

Am 17.12.2021 15:49:34 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Jaromir --

> I understand what it does and that it would change the cooperative scheduling within a priority level to the preemptive one.

As far as I understand "preemptive scheduling", this would be far from it. It would be a broken version of still cooperative scheduling. Our current higher-priority processes would, for example, happily "shuffle" around priority 40 without even intending to do so. "Processor yield" would have to reliable meaning anymore because it would seem to work without it. Until it does not.

Best,
Marcel

Am 17.12.2021 15:40:50 schrieb mail at jaromir.net <mail at jaromir.net>:
Hi Marcel,

On 2021-12-17T10:15:29+01:00, marcel.taeumel at hpi.de wrote:
>
> 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".

This is a bit unrelated to this thread but I'll ask anyway: what is so wrong with processPreemptionYields = true ? I understand what it does and that it would change the cooperative scheduling within a priority level to the preemptive one. My question is: is this behavior "just" unwanted or is there some other (technical or political) reason? Like there's code around "taking advantage" of the cooperative scheduling which would indeed break? I know Cuis use the same VM with processPreemptionYields happily set to true.

I'm not suggesting or desiring any change here, I'm just interested to know... It's been on my mind for a long time :D

Thanks a lot,

~~~
^[^ Jaromir

Sent from Squeak Inbox Talk

On 2021-12-17T10:15:29+01:00, marcel.taeumel at hpi.de wrote:
>
> 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. :-)
>
> Best,
> Marcel
> Am 16.12.2021 19:29:40 schrieb Thiede, Christoph :
> 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.
>
> Best,
> Christoph
>
> Von: Squeak-dev im Auftrag von Taeumel, Marcel
> Gesendet: Donnerstag, 16. Dezember 2021 15:53:37
> An: squeak-dev
> 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]]].
> ^ nil
>
> Best,
> Marcel
> Am 16.12.2021 14:33:51 schrieb David T. Lewis :
> 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:
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211217/94be46ca/attachment.html>