[Cuis-dev] Improved version of #terminate
Juan Vuletich
JuanVuletich at zoho.com
Wed Feb 23 09:21:40 PST 2022
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
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/28b99106/attachment-0001.htm>
More information about the Cuis-dev
mailing list