Hi Jaromir,


first of all, please let me clarify one thing:


BlockCannotReturn is an Error, of course, and thus under normal circumstances should never be resumed. Just like it would usually be an anti-pattern to resume from a subscript error, KeyNotFound error, or anything else. Not for nothing, Error implements #isResumeable with false so that sending #resume[:] to an error will usually raise an IllegalResumeAttempt.

Nevertheless, our debugger supports enforcing the resumption of an exception using Proceed, even if the exception is not marked as resumable. So this should only be used for debugging scenarios, but still, I think that we could - and maybe also should - make it as convenient as possible to perform this non-recommended operation if you are debugging some unusual scenarios. This is mainly helpful to manipulate the behavior of a program during runtime (similar to the "return entered value" in the stack list menu of the debugger).


> Resuming BlockCannotReturn sounds crazy to me by definition and you're right: it's set as resumable, I haven't noticed. I'd set it non-resumable. If a block cannot return, why should we be tempted to do that? :)


I don't know whether there was a special reason to mark it as resumable, but if there wasn't one, I totally agree with you on this point! Just talkin' about the conscious decision of the debugging person to ignore the non-resumability of this exception and resume it anyway, just like you can do it for any other normal error. :-)


> >     `a := [true ifTrue: [^ 1]. 2].`
> >     "Both statements need to be executed separately in a Workspace so that [a outerContext sender] becomes nil!"
> >     `a value.`
> > In this situation, it is valid to resume from BlockCannotReturn and currently also possible in the Trunk. Note that BlockCannotReturn even overrides #isResumable to answer true, though the class comment discrecommends resuming it.
>
> My interpretation of this example is the home sender of  ^1 is gone once the first do-it ends. So the second do-it correctly, in my opinion, invokes the cannot return error. Current Trunk returning 2 seems  wildly incorrect to me.

Again, just for clarification: The example does raise a BlockCannotReturn in the second expression in the current Trunk as it should do. :-) Maybe my explanation was not precise enough here. I was only referring to the unusual edge case in which you attempt to proceed the process from this BlockCannotReturn error. In the Trunk, the expression will return 2 in this case. With your example, you won't be able to escape from the situation without pressing Abandon.

> [
>         [
>                 [ ] ensure: [
>                         [] ensure: [
>                                 ^Transcript show: 'x1'].
>                         Transcript show: 'x2']
>         ] ensure: [
>                 Transcript show: 'x3'].
>         Transcript show: 'x4'
> ] fork
>
> In this case the expected outcome is ---> x1 x3. Neither x2 nor x4 should be printed (x2 is intentionally skipped by the non-local return and x4 is outside the ensure blocks). With the fix you propose the outcome is either ---> x1 x2 x3 if pressed Abandon or ---> x1 x2 x3 x4 if pressed Proceed - this would be equivalent to no non-local return at all :)

Wait, wait, wait. This smells to me. :-) #cannotReturn: should not be *resumed* after the error was abandoned. Otherwise, something is wrong with the termination logic. Process >> #terminate *must not* resume in this place. Terminating means only executing all uncompleted unwind contexts. I just reverted to the version ct 1/17/2021 18:35 of Process >> #terminate and with regard to your example, both implementations of #cannotReturn: behave the save (---> x1 x3) as expected. Hm, I'm sorry, but Process >> #terminate is not yet done correctly IMHO. I'll send you another message concerning this method soon, but I'm checking many things while drafting the message, so please have some more patience. :-)

> Thanks for discussing this!

Thank *you* for whipping the "machine room" of Squeak into shape again and bringing up all these interesting questions along the way! :-)

Best,
Christoph


________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jaromir Matas <m at jaromir.net>
Gesendet: Samstag, 15. Mai 2021 23:20:54
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] The Inbox: Kernel-ct.1405.mcz

Hi Christoph,

> Counterproposal to Kernel-jar.1404 for fixing VM crashes when resuming
> from a BlockCannotReturn. Instead of enforcing retrial, repair the context
> stack if the receiver has ended.

I was considering the idea whether it could make sense to "fix" the stack
but dumped it eventually because it would completely change the semantics of
non-local returns. In my opinion once the home context sender is not
available it means it's gone irreparably. There are two situation to
consider: double return to the same context within one stack (e.g. the
return context is gone or it may even still exist but its pc has moved) or
the home sender is on a different context stack - in case of forks etc.
Non-local returns between forks could in theory work but not in the current
environment; Squeak strictly requires the home context sender to be on the
same stack.



> Not in all situations, the receiver of #cannotReturn: is actually unable
> to resume. Consider this example for a disproof:
>     `a := [true ifTrue: [^ 1]. 2].`
>     "Both statements need to be executed separately in a Workspace so that
> [a outerContext sender] becomes nil!"
>     `a value.`
> In this situation, it is valid to resume from BlockCannotReturn and
> currently also possible in the Trunk. Note that BlockCannotReturn even
> overrides #isResumable to answer true, though the class comment
> discrecommends resuming it.

My interpretation of this example is the home sender of  ^1 is gone once the
first do-it ends. So the second do-it correctly, in my opinion, invokes the
cannot return error. Current Trunk returning 2 seems wildly incorrect to me.

Resuming BlockCannotReturn sounds crazy to me by definition and you're
right: it's set as resumable, I haven't noticed. I'd set it non-resumable.
If a block cannot return, why should we be tempted to do that? :)



> Nevertheless, this raises another question - what would you expect from
> this
> example to return?
>
> `a := [true ifTrue: [^ 1] yourself].`
> "Both statements need to be executed separately in a Workspace so that [a
> outerContext sender] becomes nil!"
> `[a value] on: BlockCannotReturn do: [:ex | ex resume].`
>
> Should it be 1 or nil? In the Trunk, is it nil, if we override
> \#defaultResumeValue as below, it will be 1.

This is a mean example... My fix ended in an infinite loop :)  I tried to
fix it but the only clean solution that occurred to me is to set
BlockCannotReturn as non-resumable.

But again, my interpretation here is any attempt to "repair" the context
that cannot return means a substantial change of the non-local return
semantics. It means I'd return nil because the meaning of the error is: I
cannot return 1 to my home sender. Here's one of my examples I'm planning to
send as test cases to the Inbox soon:

[
        [
                [ ] ensure: [
                        [] ensure: [
                                ^Transcript show: 'x1'].
                        Transcript show: 'x2']
        ] ensure: [
                Transcript show: 'x3'].
        Transcript show: 'x4'
] fork

In this case the expected outcome is ---> x1 x3. Neither x2 nor x4 should be
printed (x2 is intentionally skipped by the non-local return and x4 is
outside the ensure blocks). With the fix you propose the outcome is either
---> x1 x2 x3 if pressed Abandon or ---> x1 x2 x3 x4 if pressed Proceed -
this would be equivalent to no non-local return at all :)

I hope I'll be able to put the tests together and publish in a few days.

Juan Vuletich showed me a beautiful example about the non-local return
semantics - take a look in [1] in the middle of the post.

Thanks for discussing this!

best,

[1] [[Cuis-dev\] Unwind mechanism during termination is broken and
inconsistent](https://lists.cuis.st/mailman/archives/cuis-dev/2021-April/003055.html)





-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Smalltalk - Squeak - Dev | Mailing List Archive<http://forum.world.st/Squeak-Dev-f45488.html>
forum.world.st
Squeak - Dev forum and mailing list archive. The general-purpose Squeak developers list




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210517/3230cb86/attachment.html>