[Cuis-dev] Changes to unwind logic and termination

[Juan Vuletich]

Hi Jaromir,

On 2025-11-19 6:15 AM, Jaromir Matas via Cuis-dev wrote:
> 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 :)

Well, we need to find out how to make it possible for you to join us 
next year! You'd have a great time. I promise. BTW do you usually attend 
ESUG conference? Maybe we can meet there next year too.

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

Yes. There were several other really good presentations, and all of them 
were recorded. They will be published on YouTube, like those of rpevious 
years.

>> 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 think the analysis you did with Christoph makes total sense. It is 
better this way. So, I just pushed your code.

> 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.

I just removed that test, and replaced it with a possibly redundant 
#testTerminateWithEmptyUnwindBlock, just to document all this a bit.

>
> Thanks again and best regards,
> Jaromir

Thank you. Cheers!

-- 
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20251119/2e18a815/attachment-0001.htm>