<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Jaromir --<div><br></div><div>If you do new stuff, try to base it on some recent version in Trunk, not some older version in the Inbox.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 09.06.2022 11:41:02 schrieb Jaromir Matas <mail@jaromir.net>:</p><div style='font-family:Arial,Helvetica,sans-serif'>
<div class="WordSection1">
<p class="MsoNormal">Hi Marcel,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> <span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">
Due to that ancestry of 1478, 1475 is now in Trunk as well. Is this a problem or did you revise your concerns from here?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I really need more education about this :) I just kept piling the changes without thinking… 1475 was insufficient and was updated (superseded?) by 1476. I don’t know what the consequences of keeping 1475 in the Trunk are though. From my
 naïve position as long as the contents of 1475 doesn’t show up in the versions history, I’m ok.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you!</p>
<p class="MsoNormal">Best,</p>
<p class="MsoNormal">Jaromir</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNoSpacing"><span lang="CS">--</span></p>
<p class="MsoNoSpacing"><strong><span style="font-family:"Calibri Light",sans-serif;color:#333333;font-weight:normal">Jaromír Matas</span></strong><span style="font-family:"Calibri Light",sans-serif;color:#555555"><o:p></o:p></span></p>
<p class="MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:#2E75B6">mail@jaromir.net</span></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>Thursday, June 9, 2022 10:30<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev</a><br>
<b>Subject: </b>Re: [squeak-dev] The Inbox: Kernel-jar.1475.mcz</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">Due to that ancestry of 1478, 1475 is now in Trunk as well. Is this a problem or did you revise your concerns from here?<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">
<p style="margin-top:7.5pt"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: #AAAAAA">Am 06.06.2022 11:21:13 schrieb Jaromir Matas <mail@jaromir.net>:<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">Hi Marcel,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">I’d like to withdraw this changeset; I still think the assumption that the process terminating another
 process should wait until the termination is completed is valid but it’ll need some more thinking: one of the side-effects is if you terminate a process like this:<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">                p := [  [Semaphore new wait] ensure: [^2] ] fork.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">From the UI, like this:<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">                p terminate<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">you freeze the UI – because it waits for p to terminate but p attempts to open a debugger in the UI :)<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">Something like this
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">                q := [p terminate] fork<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">works fine, indeed.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">So my suggestion is to leave #terminate as is (it’s still an improvement against the previous) and keep
 the 'testTerminateWithDelayInUnwind' in expected failures as a reminder. The rest of the tests I sent earlier are still valid.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">Best,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNoSpacing"><span lang="CS" style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">--</span><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"><o:p></o:p></span></p>
<p class="MsoNoSpacing"><strong><span style="font-size: 10.0pt;font-family: "Calibri Light",sans-serif;color: #333333;font-weight: normal">Jaromír Matas</span></strong><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"><o:p></o:p></span></p>
<p class="MsoNoSpacing"><span style="font-size: 10.0pt;font-family: "Calibri Light",sans-serif;color: #2E75B6">+420 777 492 777</span><span style="font-size: 10.0pt;font-family: "Calibri Light",sans-serif;color: #555555"><br>
</span><span style="font-size: 10.0pt;font-family: "Calibri Light",sans-serif;color: #2E75B6">mail@jaromir.net</span><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">From:
</span></b><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"><a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a><br>
<b>Sent: </b>Saturday, June 4, 2022 22:32<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a><br>
<b>Subject: </b>[squeak-dev] The Inbox: Kernel-jar.1475.mcz<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black">A new version of Kernel was added to project The Inbox:<br>
<a href="http://source.squeak.org/inbox/Kernel-jar.1475.mcz">http://source.squeak.org/inbox/Kernel-jar.1475.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Kernel-jar.1475<br>
Author: jar<br>
Time: 4 June 2022, 10:31:44.661893 pm<br>
UUID: 923d5402-9a8d-0a48-87d7-44c56400dd0c<br>
Ancestors: Kernel-jar.1474<br>
<br>
Fix a scenario when a delay or yield inside unwind blocks may cause control be handed over to the original process which may be assuming the termination has completed. (A higher priority for termination is indeed not a solution)<br>
<br>
A process that invokes termination of another process is assumed to wait until the terminating process finishes unwinding itself. This may be useful during cleanup operations requiring e.g. waiting for resources etc.<br>
<br>
A complementing test 'testTerminateWithDelayInUnwind' is part of the additional collection of tests in KernelTests-jar.428.<br>
<br>
=============== Diff against Kernel-jar.1474 ===============<br>
<br>
Item was changed:<br>
  ----- Method: Process>>terminate (in category 'changing process state') -----<br>
  terminate <br>
         "Stop the process that the receiver represents forever.<br>
          Unwind to execute pending #ensure:/#ifCurtailed: blocks before terminating;<br>
+         allow all unwind blocks to run; if they are currently in progress, let them finish."<br>
-         allow all unwind blocks to run; if they are currently in progress, let them finish.<br>
-         If the process is in the middle of a #critical: critical section, release it properly."<br>
         <br>
+         "This is the kind of behavior we expect when terminating a healthy process.<br>
-        "This is the kind of behavior we expect when terminating a healthy process.<br>
          See further comments in #terminateAggressively and #destroy methods dealing
<br>
+         with process termination when closing the debugger or after a catastrophic failure.<br>
+         <br>
+         If terminating the active process, create a new stack and run unwinds from there.<br>
-         with process termination when closing the debugger or after a catastrophic failure."<br>
         <br>
+         If terminating a suspended process (including runnable and blocked), always<br>
+         suspend the terminating process first so it doesn't accidentally get woken up.
<br>
+         Equally important is the side effect of the suspension: In 2022 a new suspend<br>
+         semantics has been introduced: the revised #suspend backs up a process waiting<br>
+         on a conditional variable to the send that invoked the wait state, while the previous<br>
+         #suspend simply removed the process from the conditional variable's list it was<br>
+         previously waiting on; see #suspend and #suspendAndUnblock comments.<br>
-        "If terminating the active process, create a parallel stack and run unwinds from there;<br>
-         if terminating a suspended process, again, create a parallel stack for the process being<br>
-         terminated and resume the suspended process to complete its termination from the new<br>
-         parallel stack. Use a priority higher than the active priority to make the process that<br>
-         invoked the termination wait for its completion."<br>
  <br>
+         If the process is in the middle of a #critical: critical section, release it properly.<br>
+        <br>
+         To allow a suspended process to unwind itself, create a new stack for the process<br>
+         being terminated and resume the suspended process to complete its termination<br>
+         from the new parallel stack. Use a semaphore to make the process that invoked<br>
+         the termination wait for self's completion. Execute the termination in the ensure<br>
+         argument block to ensure it completes even if the terminator process itself gets<br>
+         terminated before it's finished; see testTerminateInTerminate."<br>
+        <br>
-        "If terminating a suspended process (including runnable and blocked), always suspend<br>
-         the terminating process first so it doesn't accidentally get woken up. Equally important is<br>
-         the side effect of the suspension; In 2022 a new suspend semantics has been introduced:<br>
-         the revised #suspend backs up a process waiting on a conditional variable to the send that<br>
-         invoked the wait state, while the pre-2022 #suspend simply removed the process from<br>
-         the conditional variable's list it was previously waiting on; see Process>>suspend comments.<br>
-         Execute the termination in the ensure argument block to ensure it completes even if the
<br>
-         terminator process itself gets terminated before it's finished; see testTerminateInTerminate."<br>
- <br>
         | context |<br>
         self isActiveProcess ifTrue: [<br>
                 context := thisContext.<br>
                 ^[context unwindTo: nil. self suspend] asContext jump].<br>
  <br>
+        [] ensure: [ | terminator |<br>
-        [] ensure: [ <br>
                 self suspendAndReleaseCriticalSection.<br>
                 context := suspendedContext ifNil: [^self].<br>
+                terminator := Semaphore new.<br>
+                suspendedContext := [context unwindTo: nil. terminator signal. self suspend] asContext.<br>
+                self priority: Processor activePriority; resume.<br>
+                terminator wait]!<br>
-                suspendedContext := [context unwindTo: nil. self suspend] asContext.<br>
-                self priority: (Processor activePriority + 1 min: Processor highestPriority); resume]!<br>
<br>
<br>
<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-right:.5in;mso-margin-bottom-alt:auto">
<span style="font-size: 10.0pt;font-family: "Arial",sans-serif;color: black"> <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div></blockquote>
                                        </div></body>