<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=utf-8">
<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;}
@font-face
{font-family:"Calibri Light";
panose-1:2 15 3 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;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.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"><span lang="CS">Hi Eliot,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">I'm finally starting to understand :)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">The real reason why we need #terminateTo: in the image is the implementation of StackInterpreter >> #commonReturn.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">There are two non-trivial scenarios:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">1) home is on the sender chain and no unwind context is found -> then just return internally inside the VM and (!) mark all intervening contexts/pages as returned from (nil pc and sender); this is effectively as if executing
terminateTo.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">2) home is on the sender chain and an unwind context's found -> then the vm just sends aboutToReturn and lets the image deal with the unwinds.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">And this is, in my opinion, the real reason why we need to call #terminateTo: *in the image*, to make the two scenarios behave consistently, because otherwise the result of a return would depend on the presence/absence of
unwind blocks.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Example:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">Define a test method:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Object >> testMe<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"> [^[^2]] ensure: []<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">and inspect 'self testMe'<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">--> the returned closure will have a *dead* outerContext as expected.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Now, in Context >> #resumeEvaluating: aBlock through: firstUnwindCtxtOrNil replace
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">'thisContext terminateTo: self.' <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">with <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">'thisContext privSender: self.'<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">and inspect 'self testMe'<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">--> the returned closure will have the outerContext *very much alive*.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">If you define the test method *without* the ensure:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Object >> testMe<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"> ^[^2]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Then in both cases 'self testMe' will return a closure with a *dead* outerContext.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">And this inconsistency is bad indeed.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">> Let’s imagine that somewhere along the chain between the receiver and argument of terminateTo: a block with a up arrow return was created whose home was on that chain. Were the contexts not marked as having been returned
from then a subsequent activation of the block might actually be able to return.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Yes! here's an example:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">testMe<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"> self returnTwo: [:returnTwo | [^returnTwo] ensure: []]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">returnTwo: aBlock<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"> aBlock value: [^2]<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">If you do 'self testMe value'<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">then for #teminateTo: replaced with #privSender: (in #resumeEvaluating:through: as in the previous example) the computation will subsequently activate the inside block [^2] and return from it too without any accident. (Note:
for some reason when debugging, the computation returns from both blocks and then nicely continues but when running normally, it returns from both blocks as in simulation but then raises a cannot return error later, from another return; apparently, the VM
doesn't like something there while the debugger sees no problem.)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Eliot, many thanks for your patience. If the above makes sense I'd like to send a test covering #terminateTo along with an explanation.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">PS: there's a recent note in the comments in StackInterpreter >> #commonReturn:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">"We must move any frames on intervening pages above the frame linked to because these may be in use, e.g. via co-routining"<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS">Does it suggest not all frames are marked as returned from after all, perhaps? :)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="CS"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="CS">Best,</span></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<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#8FAADC"><o:p> </o:p></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:eliot.miranda@gmail.com">Eliot Miranda</a><br>
<b>Sent: </b>Monday, February 20, 2023 4:51<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">The general-purpose Squeak developers list</a><br>
<b>Subject: </b>Re: [squeak-dev] Questions about FullBlock closures</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Jaromir,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">On Feb 18, 2023, at 11:04 PM, Jaromir Matas <mail@jaromir.net> wrote:<o:p></o:p></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">> No, the difference is that the pc and sender of the contexts between the receiver and argument contexts are set to nil when one does terminateTo: but not when one does privSender:. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">This is crystal clear, no problem here<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">> Clearly they *must* be do professed yo be marked as having been returned from
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">And this is precisely where I‘m lost: Why do the (cut out) contexts *<b>need</b>* to be marked as returned from? In order to be GC’d? Otherwise they’d get stuck? Looking at StackInterpreterPrimitives >> #primitiveTerminateTo there’s a lot
going on with frames and pages too but when I replace terminateTo: with privSender: in my image (two/three senders only), seemingly everything works as before (tests ok etc) which drives me crazy :)
<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Remember we talked about blocks and non-local return? Let’s imagine that somewhere along the chain between the receiver and argument of terminateTo: a block with a up arrow return was created whose home was on that chain. Were the contexts
not marked as having been returned from then a subsequent activation of the block might actually be able to return. This is a no no.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks for your patience,<o:p></o:p></p>
<p class="MsoNormal">Jaromir<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
Eliot<o:p></o:p></p>
<div>
<p class="MsoNormal">_,,,^..^,,,_ (phone)<o:p></o:p></p>
</div>
<div id="AppleMailSignature">
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">On Feb 17, 2023, at 2:45 PM, Jaromir Matas <mail@jaromir.net> wrote:<o:p></o:p></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">Hi Eliot, Tim, all</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">> Eliot: But I suspect that atomicity is not crucial and that therefore the terminateTo: primitive is only an optimization.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">That explains why the *primitive* is not essential; another question is whether #terminateTo: as such (primitive or not) is essential for e.g. freeing the stack frames/pages or "just" an optimization.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">I'll try to answer this question. After reading Eliot's post at http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/ and checking Tim's primitiveTerminateTo: code, my guess is that the
difference between</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">thisContext terminateTo: someContext.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">and</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">thisContext privSender: someContext.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">is that in the former case the stack frames/pages are being freed immediately, while in the latter case the whole sender chain remains intact until it is, sooner or later, GCd or, if referenced, remains available for further
use (whatever it may be).</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">No, the difference is that the pc and sender of the contexts between the receiver and argument contexts are set to nil when one does terminateTo: but not when one does privSender:. Clearly they *must* be do professed yo be marked as having
been returned from (c.f. earlier parts of the conversation).<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">That may be why using #terminateTo: (primitive or not) is not essential, but an optimization. Too naive? :) Could there be, perhaps, some circularities that need breaking? Or is GC too slow to clean up after non-local returns?
(btw I only found two senders of #terminateTo: - #runUntilErrorOrReturnFrom: and #resume:[through:]).</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">Oops… more questions popping up </span>:)<o:p></o:p></p>
<p class="MsoNormal"><span lang="CS"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">Best,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="CS">Jaromir</span><o:p></o:p></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></p>
<p class="MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:#2E75B6">mail@jaromir.net</span></p>
<p class="MsoNormal"><span style="color:#8FAADC"> </span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From: </b><a href="mailto:mail@jaromir.net">Jaromir Matas</a><br>
<b>Sent: </b>Sunday, February 12, 2023 21:06<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">The general-purpose Squeak developers list</a><br>
<b>Subject: </b>Re: [squeak-dev] Questions about FullBlock closures<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hi Eliot, Tim,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">thanks a lot for your answers.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">> peek at the generated gcc3x-cointerp.c file and find the primitiveTerminateTo() routine<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Awfully complex :) <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">> But I suspect that atomicity is not crucial and that therefore the terminateTo: primitive is only an optimization.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">To be sure I understand, please let me try from another angle:
<o:p></o:p></p>
<p class="MsoNormal">Consider a thought experiment: What happens if, in Context >> #resumeEvaluating:, we replace<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> thisContext terminateTo: self.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">with:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> thisContext privSender: self.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Would garbage collection/the vm take care of freeing the intervening contexts/frames or is in fact #terminateTo: prim 196 essential for this?<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">When I try that, nothing wrong seems to happen and all tests (Exception, Process, Methods, Object, Classes) work fine but I'm only looking at the surface of things indeed.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">What I'm trying to achieve is to reuse the existing #unwindTo: method in #resumeEvaluating:, which seems to work fine, and just wonder whether replacing the #terminateTo: with #privSender: would further simplify the method (or made the
system less efficient):<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Context>>resumeEvaluating: aBlock<o:p></o:p></p>
<p class="MsoNormal"> "Unwind thisContext to self and resume with value as result of last send.
<o:p></o:p></p>
<p class="MsoNormal"> Execute unwind blocks when unwinding.<o:p></o:p></p>
<p class="MsoNormal"> ASSUMES self is a sender of thisContext"<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> self isDead ifTrue: [self cannotReturn: aBlock value to: self].<o:p></o:p></p>
<p class="MsoNormal"> thisContext <o:p></o:p></p>
<p class="MsoNormal"> unwindTo: self safely: false;<o:p></o:p></p>
<p class="MsoNormal"> terminateTo: self.<o:p></o:p></p>
<p class="MsoNormal"> ^aBlock value<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">best,<o:p></o:p></p>
<p class="MsoNormal">Jaromir<o:p></o:p></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></p>
<p class="MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:#2E75B6">mail@jaromir.net</span></p>
<p class="MsoNormal"><span style="color:#8FAADC"> </span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From: </b><a href="mailto:eliot.miranda@gmail.com">Eliot Miranda</a><br>
<b>Sent: </b>Sunday, February 12, 2023 16:54<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">The general-purpose Squeak developers list</a><br>
<b>Subject: </b>Re: [squeak-dev] Questions about FullBlock closures<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hi Jaromir,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">On Feb 12, 2023, at 5:13 AM, Jaromir Matas <mail@jaromir.net> wrote:<o:p></o:p></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">>> What is the purpose of the primitive 196 Context>>#terminateTo:?
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">> Strongly related to prim 195 & 197. You have to check each context up the chain to see what exceptions might be dealt with & by which context.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">My understanding is prim 195 (#findNextUnwindContextUpTo:) searches for unwind contexts and prim 197 (#findNextHandlerContextStarting) searches for handler context. But prim 195 (#terminateTo:) is unclear to me. #terminateTo comment says:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">"Terminate all the Contexts between me and previousContext, if previousContext is on my Context stack. Make previousContext my sender."<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Which doesn't say much except it's nilling all context's pc and sender between self and the argument. I wonder what else it does behind the scenes and why :)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In a paper from 2009 Eliot wrote:<o:p></o:p></p>
<p class="MsoNormal">"[...] there’s a primitive terminateTo: that does something similar to the context nilling in non-local return. It is a little simpler than non-local return (although not much) but it is just a variation on the same theme so I’ll spare
you."<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I wish Eliot didn't spare us :) Other than that I haven't found any further info.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Because the primitive 196 dates back to 2001 I'm unable to judge whether it's still essential to nil the intermediate contexts (to free stack pages or something).
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">In particular I'm trying to understand whether the use of #terminateTo *<b>primitive</b>* in #resumeEvaluating: and #resume:through: is essential or not.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">There are three things that primitive 296, Context>>terminateTo: does, or rather there are two things it does, and it does them in a particular way. It sets senders and pcs of intervening contexts to nil. It sets the sender of the receiver
to the argument. If does this atomically.<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I can’t say whether the last of these is necessary. If it is, then the primitive is needed, essential. But the primitive merely optimized the former two operations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In the StackInterpreter & CoInterpreter it provides a significant optimization because<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- the primitive avoids creating any contexts; if if were not implemented primitively then contexts would have to be created for all intervening frames, merely to throw unreferenced ones away<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- intervening stack pages can be freed without looking at their contents <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">So the primitive is an important optimization for Stack/CoInterpreter.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">But I suspect that atomicity is not crucial and that therefore the terminateTo: primitive is only an optimization.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"> Any additional info greatly appreciated.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">HTH<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Jaromir<o:p></o:p></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></p>
<p class="MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:#2E75B6">mail@jaromir.net</span></p>
<p class="MsoNormal"><span style="color:#8FAADC"> </span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From: </b><a href="mailto:tim@rowledge.org">tim Rowledge</a><br>
<b>Sent: </b>Sunday, February 12, 2023 5:18<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org">The general-purpose Squeak developers list</a><br>
<b>Subject: </b>Re: [squeak-dev] Questions about FullBlock closures<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:2.5in;margin-bottom:12.0pt;margin-left:2.5in">
<br>
<br>
> On 2023-02-11, at 4:04 PM, Jaromir Matas <mail@jaromir.net> wrote:<br>
> <br>
> If I may, I have a question here: What is the purpose of the primitive 196 Context>>#terminateTo:? Why primitive and why terminating each context along the way? Naively, I'd think checking the two contexts are in the same sender chain and patching them via
privSender should do but I'm sure I'm missing something here :)<br>
> <br>
<br>
Exception handling stuff. Strongly related to prim 195 & 197. You have to check each context up the chain to see what exceptions might be dealt with & by which context. Look at e.g. Process>>#terminate for some context.<br>
<br>
<br>
tim<br>
--<br>
tim Rowledge; tim@rowledge.org; <a href="http://www.rowledge.org/tim">http://www.rowledge.org/tim</a><br>
When flying inverted, remember that down is up and up is expensive<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:1.0in;margin-bottom:5.0pt;margin-left:1.0in">
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:.5in;margin-bottom:5.0pt;margin-left:.5in">
<o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>