[Cuis-dev] Changes to unwind logic and termination

Jaromir Matas mail at jaromir.net
Wed Nov 19 01:15:12 PST 2025


Hi Juan,

On Nov 18 2025, at 10:33 pm, Juan Vuletich via Cuis-dev
<cuis-dev at lists.cuis.st> wrote:

> Hi Jaromir,
>  
> Apologies for the delayed answer. We were midst the FAST Smalltalks  
> conference in Argentina and a wonderful course on VM internals by
> Eliot  

What a treat! I just regret Buenos Aires is so far away from Prague :)

I know Eliot had a presentation at Smalltalks 2025; any chance the
presentation was recorded?

> and I didn't have any brains left for anything else for a while.
>  
> I just reviewed your changes. These are welcome and important enhancements.
>  
> Thank you for keeping us updated and sinc'ed with Squeak! This is most  
> valuable!
>  

All pleasure's mine; Cuis is an invaluable source of feedback and
inspiration. Thank you!

>
> When I loaded your changes, I found that in #unwindTo:safely: the old  
> version had a guard against (ctx tempAt: 1) being nil. Your new code  
> doesn't include that guard, and #testTerminateWithNiledUnwindBlock
> will  
> fail. You can also see this with your 'Workspace example' included at  
> that test:
>  
>     Workspace example:
>     p := [[Processor activeProcess suspend] ensure: nil] newProcess.
>     p resume.
>     [p terminate] fork
>  
> I found that adding a simple #ifNotNil: appears to solve the issue.  

I originally added the nil check and the test but we have discussed this
issue with Christoph Thiede recently and decided to remove the check.
There's no point to guard against nil in place of an unwind block as
it's apparently just a user error and should show up. Only a block
should be allowed as an unwind block. Potentially, the nil check could
even obscure a user's error and make debugging harder (perhaps). This
way the user should be able more quickly identify the error in the Debugger.

On the other hand we have a slight inconsistency here: if you run

    [] ensure: nil

nothing happens, because we have `Object >> #value` returning self :)  

So frankly, I don't have a strong opinion here. A guard is ok too or you
could even use the nil check to raise an explicit error if you prefer.  

In such case one should probably add the same guard to
#unwindAndResume:evaluating: too.

I'm surprised I forgot to add the test to Squeak :) So depending on your
decision it might want to be moved to expected failures.

Thanks again and best regards,
Jaromir


> Please check the attached revision of your change set. I also added
> your  
> email as a comment in the change set postscript for future reference.
> If  
> you think this version is correct, I'll push it to GitHub immediately.
>  
> Thanks a lot!
>  
> Cheers,
>  
> On 2025-11-09 5:34 PM, Jaromir Matas via Cuis-dev wrote:
>> Hi Juan,
>>  
>> Recently I've done some cleanup/fixing in Squeak and thought you might
>> want to take a look and perhaps integrate to Cuis. Some of the changes
>> are already part of the Squeak Trunk, the rest waiting to be merged.
>>  
>> The changes are in the following areas:
>>  
>> 1) ContextPart return & resume suite of methods - all simplified and
>> redirected straight to the unified #unwindAndResume:evaluating: method;
>> removing some now obsolete (#return:through: and #resume:through:) -
>> please let me know whether you prefer to go via deprecation like Squeak
>> or delete them right away (they should not really have been used as
>> public anywhere, their only purpose was to serve to
>> #aboutToReturn:through:). No change in functionality, just improved readability.
>>  
>> 2) slightly simplified #terminate and #runUntilReturnFrom:
>>  
>> 3) the unwind control logic around #ensure:/#ifCurtailed: enriched by an
>> additional value to track the completion status of the unwinding -> see
>> #unwindAndResume:evaluating:, #unwindTo:safely:, and
>> #finishIncompleteUnwindsUpTo: (The reason for this change is a
>> suspension point on the backward branch of the unwind loop which was
>> observed to cause termination failures under heavy multithreaded load
>> by Christoph).
>>  
>> 4) *finally* really cleanly fixing the "step-over bug" - see
>> Process>>complete - and reverting #return:from:
>>  
>> 5) fixing a little bug hiding in #runUntilErrorOrReturnFrom:
>>  
>> 6) reworked many comments
>>  
>> I'd be very thankful if you could review the changes and let me know if
>> you spot anything suspicious; tests are green in both Cuis and Squeak.
>>  
>> I look forward to your feedback.
>>  
>> best,
>> Jaromir
>>  
> --  
> Juan Vuletich
> www.cuis.st
> github.com/jvuletich
> researchgate.net/profile/Juan-Vuletich
> independent.academia.edu/JuanVuletich
> patents.justia.com/inventor/juan-manuel-vuletich
> --  
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
> 


More information about the Cuis-dev mailing list