[squeak-dev] Questions about FullBlock closures

Eliot Miranda eliot.miranda at gmail.com
Sun Feb 12 20:48:49 UTC 2023


oops, 296 => 196

On Sun, Feb 12, 2023 at 7:53 AM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Jaromir,
>
> On Feb 12, 2023, at 5:13 AM, Jaromir Matas <mail at jaromir.net> wrote:
>
> 
>
> Hi,
>
>
>
> >> What is the purpose of the primitive 196 Context>>#terminateTo:?
>
>
>
> > 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.
>
>
>
> 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:
>
>
>
> "Terminate all the Contexts between me and previousContext, if
> previousContext is on my Context stack. Make previousContext my sender."
>
>
>
> 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 :)
>
>
>
> In a paper from 2009 Eliot wrote:
>
> "[...] 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."
>
>
>
> I wish Eliot didn't spare us :) Other than that I haven't found any
> further info.
>
>
>
> 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).
>
>
>
> In particular I'm trying to understand whether the use of #terminateTo *
> *primitive** in #resumeEvaluating: and #resume:through: is essential or
> not.
>
>
> 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.
>
> 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.
>
> In the StackInterpreter & CoInterpreter it provides a significant
> optimization because
>
> - 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
>
> - intervening stack pages can be freed without looking at their contents
>
> So the primitive is an important optimization for Stack/CoInterpreter.
>
> But I suspect that atomicity is not crucial and that therefore the
> terminateTo: primitive is only an optimization.
>
>  Any additional info greatly appreciated.
>
>
> HTH
>
> Thanks,
>
> Jaromir
>
>
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>
>
>
>
> *From: *tim Rowledge <tim at rowledge.org>
> *Sent: *Sunday, February 12, 2023 5:18
> *To: *The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] Questions about FullBlock closures
>
>
>
>
>
> > On 2023-02-11, at 4:04 PM, Jaromir Matas <mail at jaromir.net> wrote:
> >
> > 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 :)
> >
>
> 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.
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> When flying inverted, remember that down is up and up is expensive
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230212/feca38c5/attachment.html>


More information about the Squeak-dev mailing list