[Cuis-dev] Improved version of #terminate
Jaromir Matas
mail at jaromir.net
Wed Feb 23 10:31:22 PST 2022
Hi Juan,
> Just pushed all your code and suggestions.
Thanks very much!
> I also removed ProceedBlockCanNotReturn.
Yes, ProceedBlockCanNotReturn is no longer required with the new terminate.
> WRT `Processor activeProcess suspend` what I did is: if the UI process is suspended, then terminate it. The reason is that starting a new UI process, and later resuming the old one, would break everything. By terminating it, I ensure it won't be resumed later.
That makes perfect sense, thanks for your explanation.
> BTW, I love the timestamp for #terminate :)
Couldn’t resist :D
Thanks again,
Jaromir
From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Wednesday, February 23, 2022 18:22
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Hi Jaromir,
Just pushed all your code and suggestions. I also removed ProceedBlockCanNotReturn. Thanks!
WRT `Processor activeProcess suspend` what I did is: if the UI process is suspended, then terminate it. The reason is that starting a new UI process, and later resuming the old one, would break everything. By terminating it, I ensure it won't be resumed later.
BTW, I love the timestamp for #terminate :)
Cheers,
On 2/22/2022 7:34 PM, Jaromir Matas via Cuis-dev wrote:
Hi Juan,
I’m enclosing an updated #terminate – the reason for the change is Eliot has implemented a new #suspend primitive with revised semantics (when suspending a process waiting on a semaphore/mutex the new suspend will back the pc counter one instruction to the send: wait) – what’s important here is the return value of #suspend will change which would break #terminate because currently you do ```oldList := self suspend``` inside #terminate. To avoid any dependency on the #suspend behavior I suggest to do ```oldList := myList``` first and then suspend the process – see the changeset.
You can verify the behavior on the new VMs:
Version 3133 backs up and returns nil
Version 3148 backs up and returns a Semaphore
Version 3154 doesn’t back up and returns a Semaphore
The enclosed #terminate should work correctly for all VM versions; you may find some tests failing for some VMs – we’ll fix this after Eliot releases a final version :)
So the point of this updated #terminate is to remove a dependency on a VM version.
Also, I’ve recently “discovered” the original #terminate in Squeak versions 1 thru 3.5 – very elegant and simple – and very similar to our latest version :) Check this #teminate from 1999:
terminate
"Stop the process that the receiver represents forever."
| context |
Processor activeProcess == self
ifTrue:
[thisContext unwindTo: nil.
thisContext sender == nil ifFalse:
[thisContext sender release].
thisContext removeSelf suspend]
ifFalse:
[myList == nil
ifFalse:
[myList remove: self ifAbsent: [].
myList _ nil].
context _ suspendedContext.
suspendedContext _ nil.
context == nil ifFalse: [context unwindTo: nil].
(context ~~ nil and: [context sender ~~ nil])
ifTrue: [context sender release]]
Thanks,
Jaromir
From: Jaromir Matas via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Thursday, February 3, 2022 13:00
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>; Juan Vuletich<mailto:JuanVuletich at zoho.com>
Cc: Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Hi Juan,
I guess this situation should be recoverable via Alt + . as well:
```
Processor activeProcess suspend
```
I’ve updated all the examples and enclosing a fileout. Replacing strings with symbols (to print results) has an advantage that you can evaluate the examples directly inside the Process >> terminateExamples method while keeping the cool option to export them to a Workspace.
I’ve tested the examples in Part 5 with Eliot’s fix of the MNU recursion. The notes mention the fix explicitly to avoid confusion. Also, I used the original #cannotReturn (see the previous email). It’s safer to assume the image may crash after proceeding the #cannotReturn anyway.
I was considering to put each of the examples to a separate method but I think having them all in a Workspace is more convenient - to compare the examples etc.
Have a nice day,
Jaromir
From: Jaromir Matas via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Thursday, February 3, 2022 1:17
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>; Juan Vuletich<mailto:JuanVuletich at zoho.com>
Cc: Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Hi Juan,
apologies, forgot to enclose a helper method to Eliot’s MNU fix for your review.
Best,
Jaromir
From: Jaromir Matas via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Thursday, February 3, 2022 0:49
To: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Hi Juan,
Works perfectly, thanks! I’m reviewing all examples and updating the expected results. I’ve also replaced strings with symbols so we won’t have to struggle with the quotes :)
I’d like to ask you to make two additional changes:
1. revert MethodContext >> cannotReturn: back to your original version (enclosed fileout fyi). The latest #terminate doesn’t need the newer modified version any longer and works better with the original one and, what’s more important, the newer one breaks one of the examples (interestingly doesn’t break any test). Generally it’s better if #terminate’s good behavior is not dependent on #cannotReturn (the new terminate detects and avoids executing it).
2. please review the enclosed Eliot’s modification of Object >> doesNotUnderstand dealing with infinite recursion of the MNU error if you keep proceeding the error without doing any modification to the message not understood. The current doesNotUnderstand recursive behavior impacts some terminate examples with the MNU error involved and Eliot’s modification fixes it – what it does it checks whether the next MNU error has identical conditions and prevents the loop. If you agree to merge it I’ll update the examples accordingly. The loop only occurs when the MNU error happens inside an unwind block, which is rare but I’d prefer to have it clean :)
Thanks very much,
Jaromir
From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Wednesday, February 2, 2022 23:32
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Thanks Jaromir.
The test is integrated. I also fixed the format in #terminateExamples.
WRT User Interrupt, in Cuis I recently changed to usually interrupt whatever process was running the moment Alt + . was pressed. I think this makes sense. If the process happens to be the background process, it refuses to do it, as the VM requires a runnable background process at all times.
What it seems I left out, and the old code somehow did, is to create a new UI process if the previous one was terminated by any reason. Just pushed a change to do that. With the new updates, Alt + . again recovers control.
Thanks for reporting the problem!
Cheers,
On 2/2/2022 2:36 PM, Jaromir Matas via Cuis-dev wrote:
Hi Juan,
I’m reviewing the set of terminate examples and this one behaves suspiciously – it suspends the UI as expected but then the system refuses to recover via Alt + .
In Squeak the Alt + . recovery works fine. Could you please take look? Thanks!
Jaromir
[ ] ensure: [
[Processor activeProcess terminate] ensure: [
Transcript show: #x1].
Transcript show: #x2
]
"prints x1 x2 and suspends the UI; in Cuis NOT recoverable via Alt+. and prints Can not interrupt backgroundProcess (!)"
From: Jaromir Matas via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Tuesday, February 1, 2022 20:59
To: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Hi Juan,
Thank you!
I'm sending the test I owe you - #testProcessFaithfulTermination - this is a new feature of the latest terminate; the test shows the same process that created the unwind blocks also executes them during termination.
I’ll be reviewing the terminate examples and get back later.
Thanks again.
Best,
Jaromir
From: Juan Vuletich<mailto:JuanVuletich at zoho.com>
Sent: Thursday, January 27, 2022 19:21
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Jaromir Matas<mailto:mail at jaromir.net>
Subject: Re: [Cuis-dev] Improved version of #terminate
Hi Jaromir, Folks,
This is integrated and pushed to GitHub now.
Thanks,
On 1/24/2022 3:51 PM, Jaromir Matas via Cuis-dev wrote:
Hi Juan, all,
Happy to hear from you :)
Hello Jaromir, Folks,
I took a look at the code, and it looks correct to me, although I don't understand this well enough to be sure. All the tests you wrote last year pass, and that is great.
I think we'd integrate this. Still, I think it could be good to keep the current #terminate as a separate method, maybe #terminateFromForkedProcess, just in case it proves
useful in the future.
Thanks very much for reviewing the code; I think this is a good idea to keep the older version, at least for a while. I'm really happy it's been stable and nobody
complained :)
This new approach of one process using two stacks simplifies the code substantially but let's keep an eye on it, for sure. Later, if this terminate proves as
stable as the current one, the exact same approach could be used for exception unwinds too (ContextPart>>resume: etc).
I'd be very thankful if others could take a look, and better yet, try it and see if it brings any trouble.
That would be great, thanks again; any concerns or suspicions, please tell me.
Best regards,
Jaromir
--
Jaromir Matas
From: Juan Vuletich via Cuis-dev<mailto:cuis-dev at lists.cuis.st>
Sent: Monday, January 24, 2022 18:15
To: Discussion of Cuis Smalltalk<mailto:cuis-dev at lists.cuis.st>
Cc: Juan Vuletich<mailto:JuanVuletich at zoho.com>; Andres Valloud<mailto:ten at smallinteger.com>; Jaromir Matas<mailto:mail at jaromir.net>; Hernan Wilkinson<mailto:hernan.wilkinson at 10pines.com>
Subject: Re: [Cuis-dev] Improved version of #terminate
On 1/18/2022 4:07 PM, Jaromir Matas via Cuis-dev wrote:
Hi Juan, all,
I'm enclosing a new version of #terminate; I thought you might be interested to take a look and indeed, I'd be very much interested in your opinion. The termination functionality and semantics remains intact but the code is simplified and addresses Eliot's concerns regarding active process termination being done via another process. The enclosed code executes both active and suspended process’s termination directly by the process being terminated thus maintaining the invariant that the unwind blocks are executed by the same process that created them (this is the only real disadvantage of the current terminate; it’s not process faithful). The technique used is to create a parallel stack for the process being terminated and run the unwinds conveniently from there :) (thorough comments included).
I'm also enclosing some updated tests to reflect the new approach to the active process termination. If you were interested, I'd be happy to also provide updated examples and add some more tests later.
Best regards,
Jaromir
Hello Jaromir, Folks,
I took a look at the code, and it looks correct to me, although I don't understand this well enough to be sure. All the tests you wrote last year pass, and that is great.
I think we'd integrate this. Still, I think it could be good to keep the current #terminate as a separate method, maybe #terminateFromForkedProcess, just in case it proves useful in the future.
I'd be very thankful if others could take a look, and better yet, try it and see if it brings any trouble.
Thanks!
--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
@JuanVuletich
--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
@JuanVuletich
--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
@JuanVuletich
--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
@JuanVuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220223/caff6939/attachment-0001.htm>
More information about the Cuis-dev
mailing list