Hi Jaromir,

On Nov 16, 2023, at 3:23 AM, Jaromir Matas <mail@jaromir.net> wrote:


Hi Nicloas,
No no, I don't have any practical scenario in mind, I'm just trying to understand why the VM is implemented like this, whether there were a reason to leave this possibility of a crash, e.g. it would slow down the VM to try to prevent such a dumb situation (who would resume from BCR in his right mind? :) ) - or perhaps I have overlooked some good reason to even keep this behavior in the VM. That's all.

Let’s first understand what’s really happening. Presumably at tone point a context is resumed those pc is already at the block return bytecode (effectively, because it crashes in JITted code, but I bet the stack vm will crash also, but not as cleanly - it will try and execute the bytes in the encoded method trailer). So which method actually sends resume, and to what, and what state is resume’s receiver when resume is sent?



Thanks for your reply. 
Regards,
Jaromir




------ Original Message ------
From "Nicolas Cellier" <nicolas.cellier.aka.nice@gmail.com>
To "Jaromir Matas" <mail@jaromir.net>; "The general-purpose Squeak developers list" <squeak-dev@lists.squeakfoundation.org>
Date 11/16/2023 7:20:20 AM
Subject Re: [squeak-dev] Resuming on BlockCannotReturn exception

Hi Jaromir,
Is there a scenario where it would make sense to resume a BlockCannotReturn?
If not, I would suggest to protect at image side and override #resume.

Le mer. 15 nov. 2023, 23:42, Jaromir Matas <mail@jaromir.net> a écrit :
Hi Eliot, Christoph, All,

It's known the following example crashes the VM. Is this an intended behavior or a "tolerated bug"? 

`[[^ 1] on: BlockCannotReturn do: #resume] fork`

I understand why it crashes: the non-local return has nowhere to return to and so resuming the computation leads to a crash. But why not raise another BCR exception to prevent the crash? Potential infinite loop? Perhaps I'm just missing the purpose of this behavior...

Thanks for an explanation.

Best,
Jaromir

--

Jaromir Matas