[Cuis-dev] Improved version of #terminate

Juan Vuletich JuanVuletich at zoho.com
Wed Feb 2 14:31:49 PST 2022


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
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/20220202/d9d0e0dc/attachment-0001.htm>


More information about the Cuis-dev mailing list