<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 6, 2022 at 2:21 AM Jaromir Matas <<a href="mailto:mail@jaromir.net">mail@jaromir.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div lang="EN-US" style="word-wrap:break-word">
<div class="gmail-m_6624448995176542690WordSection1">
<p class="MsoNormal">Hi Marcel,</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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:</p>
<p class="MsoNormal"> p := [ [Semaphore new wait] ensure: [^2] ] fork.</p>
<p class="MsoNormal">From the UI, like this:</p>
<p class="MsoNormal"> p terminate</p>
<p class="MsoNormal">you freeze the UI – because it waits for p to terminate but p attempts to open a debugger in the UI :)</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Something like this </p>
<p class="MsoNormal"> q := [p terminate] fork</p>
<p class="MsoNormal">works fine, indeed.</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">+1</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="word-wrap:break-word"><div class="gmail-m_6624448995176542690WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Best,</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="gmail-m_6624448995176542690MsoNoSpacing"><span lang="CS">--</span></p>
<p class="gmail-m_6624448995176542690MsoNoSpacing"><strong><span style="font-family:"Calibri Light",sans-serif;color:rgb(51,51,51);font-weight:normal">Jaromír Matas</span></strong><span style="font-family:"Calibri Light",sans-serif;color:rgb(85,85,85)"><u></u><u></u></span></p>
<p class="gmail-m_6624448995176542690MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:rgb(46,117,182)">+420 777 492 777</span><span style="font-family:"Calibri Light",sans-serif;color:rgb(85,85,85)"><br>
</span><span style="font-family:"Calibri Light",sans-serif;color:rgb(46,117,182)"><a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:commits@source.squeak.org" target="_blank">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" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
<b>Subject: </b>[squeak-dev] The Inbox: Kernel-jar.1475.mcz</p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">A new version of Kernel was added to project The Inbox:<br>
<a href="http://source.squeak.org/inbox/Kernel-jar.1475.mcz" target="_blank">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>
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>