[Cuis-dev] Unwind mechanism during termination is broken and inconsistent

[Juan Vuletich]

Hi Jaromir,

On 6/5/2021 10:04 AM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> > Hi Jaromir,
>
> >
>
> > I've just pushed your latest to GitHub. I included a note with links 
> to this email thread in #terminate. I also added the new tests; and 
> your examples as a class method in Process, for future reference.
>
> You made my day, thanks :) It's been a great learning experience; I'd 
> like to thank you for your valuable comments and feedback that helped 
> me to stay on track. Also, I appreciate you keep Cuis' kernel simple 
> and compact.
>

My pleasure!

>
> I'd like to share some remarks:
>
> 1) you might ask why #complete:to: is defined in Process and not in 
> ContextPart? It should, really, but I wanted to keep it the same as in 
> Squeak for the moment :)
>

Using the same code as Squeak is a good idea for areas in the system 
where we don't chose a different approach!

> 2) there's currently a discussion (Christoph) what semantics is the 
> most appropriate for closing the debugger: If you encounter a fatal 
> error or the debugged process is damaged too badly, using #terminate 
> might be "too strong" and lead e.g. to an infinite recursion of 
> debuggers etc. For such cases a "light" version od #terminate 
> (#terminateLight) without completing the halfway through unwind 
> contexts would probably be more appropriate. For the most severe cases 
> even a Kill option without any unwinds might come in handy. I imagine 
> e.g. using #terminate for the standard closing of the debugger's 
> window and the light version of #terminate for an explicit Abandon 
> button.
>

I think that [Abandon]  should also do #terminate. And a new button 
[Kill] is preferable. (Maybe use the same button, but with [Shift], or a 
right-click menu, etc) Please don't call it "light" as it is actually 
stronger, because it does "more violence" to the process (meaning that 
the use of 'light' or 'strong' won't be obvious, and will have to be 
explained every time!). It is best to stick to standard nomenclature. 
Terminate (SIGTERM) as the default, usually safe way, and Kill (SIGKILL) 
as the last resort. These are the names used in Linux / Unix.

> 3) I'd like to raise a question about non-local return's semantics 
> during termination:
>
> ​              **What takes precedence: a termination or a non-local 
> return?**
>
> Squeak has a method `valueUninterruptably  ^ self ifCurtailed: [^ 
> self]` which in its comment says: "Even attempts to terminate (unwind) 
> this process will be halted and the process will resume here.  A 
> terminate message is needed for every one of these in the sender chain 
> to get the entire process unwound."
>
> It means Squeak authors originally intended to allow a process to 
> escape its termination via a non-local return inside an unwind block 
> but the implementation never worked.
>
> The alternative behavior is: termination takes precedence and doesn't 
> allow a non-local return to route the computation outside the unwind 
> block. This is the behavior of the current #terminate.
>
> I'd like to know your opinion about this matter; the new #terminate 
> can be amended easily to allow for non-local returns take precedence 
> over termination but I'm not sure it's really desirable - what do you 
> think?
>
> Example:
>
> ```
>
> p := [
>
>               [:exit | [Processor activeProcess suspend] "<-- 
> terminate here"
>
>                            ensure: [exit value]] valueWithExit.
>
>               Transcript show: 'escaped termination'
>
> ] newProcess resume.
>
> Processor yield.
>
> [p terminate] fork
>
> ```
>
> Current implementation will not print anything and just terminate the 
> process p because there are no unwind blocks except `[exit value]`.
>
> Originally, however, the non-local return inside `[exit value]` was 
> intended for the process p to escape termination and continue 
> executing, i.e. print 'escaped termination' and go on.
>

I have no opinion. So, I wouldn't change it unless a compelling argument 
appears.

> 4) One last comment FYI: #unwindTo: method under ContextPart in my 
> opinion suffers with the same bug as #terminate used to, and could be 
> fixed similarly (there are currently no senders however). Check this 
> example:
>
> ```
>
> p := [
>
>                            [:exit | [Processor activeProcess suspend] 
> "<-- unwind here"
>
>                                          ensure: [exit value]] 
> valueWithExit
>
>               ] newProcess resume.
>
> Processor yield.
>
> p suspendedContext unwindTo: nil
>
> ```
>
> It incorrectly produces the BlockCannotReturn error. If you do `p 
> terminate` instead of `p suspendedContext unwindTo: nil`, it works as 
> expected.
>

I guess a comment stating exactly what you say is enough, at least 
unless there is areal need for #unwindTo: If you are willing to write 
it, I'll be happy to integrate it.

> Thanks again.
>
> Best regards,
>
> Jaromir
>

Thank you!
Cheers,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210616/cf3e2469/attachment.htm>