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