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 <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.
> 
> Best,
> Christoph
> 
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> 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 <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/20211217/680de918/attachment.html>
> 
>