<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Wonderful, many thanks for your explanation; now I know what to look for! Thanks,</p>
<p class="MsoNormal">Jaromir</p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:marcel.taeumel@hpi.de">Marcel Taeumel</a><br>
<b>Sent: </b>Friday, December 17, 2021 15:55<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev</a><br>
<b>Subject: </b>Re: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi Jaromir --<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">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. :-)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Best,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Marcel <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 8.0pt;margin-left:0in;margin-top:15.0pt;margin-bottom:5.0pt;min-width: 500px">
<p style="margin-top:7.5pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#AAAAAA">Am 17.12.2021 15:49:34 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi Jaromir --<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">> I understand what it does and that it would change the cooperative scheduling within a priority level to the preemptive one.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Best,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Marcel<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 8.0pt;margin-left:0in;margin-top:15.0pt;margin-bottom:5.0pt;min-width: 500px">
<p style="margin-top:7.5pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#AAAAAA">Am 17.12.2021 15:40:50 schrieb mail@jaromir.net <mail@jaromir.net>:<o:p></o:p></span></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:1.0in;margin-bottom:5.0pt;margin-left:0in">
<span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Hi Marcel,
<br>
<br>
On 2021-12-17T10:15:29+01:00, marcel.taeumel@hpi.de wrote: <br>
> <br>
> Hi Jaromir -- <br>
> <br>
> > So the default processPreemptionYields value remains false, right? <br>
> <br>
> 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". <br>
<br>
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. <br>
<br>
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
<br>
<br>
Thanks a lot, <br>
<br>
~~~ <br>
^[^ Jaromir <br>
<br>
Sent from Squeak Inbox Talk <br>
<br>
On 2021-12-17T10:15:29+01:00, marcel.taeumel@hpi.de wrote: <br>
> <br>
> Hi Jaromir -- <br>
> <br>
> > So the default processPreemptionYields value remains false, right? <br>
> <br>
> 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". <br>
> <br>
> Hi all -- <br>
> <br>
> Thanks for fixing this issue so quickly! And -- Hooray! -- the DebuggerTests actually find regresssions. :-)
<br>
> <br>
> Best, <br>
> Marcel <br>
> Am 16.12.2021 19:29:40 schrieb Thiede, Christoph : <br>
> Hi Dave, hi Marcel, <br>
> <br>
> 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. <br>
> <br>
> > even if CMD+Dot interrupts the "[ [] repeat ] fork" from the interrupt watcher
<br>
> <br>
> How did you achieve to do this? The interrupt doesn't work for me in this situation.
<br>
> <br>
> Best, <br>
> Christoph <br>
> <br>
> Von: Squeak-dev im Auftrag von Taeumel, Marcel <br>
> Gesendet: Donnerstag, 16. Dezember 2021 15:53:37 <br>
> An: squeak-dev <br>
> Betreff: Re: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore
<br>
> <br>
> Hi Christoph, hi Dave, hi all -- <br>
> <br>
> "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.
<br>
> <br>
> Maybe you can spot the issue right away? <br>
> <br>
> ProcessorScheduler >> preemptedProcess <br>
> "Return the process that the currently active process just preempted." <br>
> self activeProcess priority to: 1 by: -1 do: [:priority | <br>
> (quiescentProcessLists at: priority) ifNotEmpty: [:list | <br>
> ^ Smalltalk processPreemptionYields <br>
> ifTrue: [list last] <br>
> ifFalse: [list first]]]. <br>
> ^ nil <br>
> <br>
> Best, <br>
> Marcel <br>
> Am 16.12.2021 14:33:51 schrieb David T. Lewis : <br>
> On Thu, Dec 16, 2021 at 11:27:09AM +0100, Marcel Taeumel wrote: <br>
> > Hi all -- <br>
> > <br>
> > I am investigating a?? regression revealed via DebuggerTests >> test01UserInterrupt. One cannot interrupt "[ [] repeat ] fork" from a do-it anymore. :-(
<br>
> > <br>
> > VM: 202112022203 (32-bit, Windows 10) <br>
> > <br>
> > Update: #20872 <br>
> > <br>
> > 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".
<br>
> > <br>
> <br>
> Confirming on Linux and also on an interpreter VM with trunk level V3 image, <br>
> so the issue is in the image, not the VM. <br>
> <br>
> Dave <br>
> <br>
> <br>
> -------------- next part -------------- <br>
> An HTML attachment was scrubbed... <br>
> URL: <br>
> <br>
> <br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>