[Cuis-dev] Follow-up: #terminate and #suspend update
Juan Vuletich
juan at cuis.st
Sat Jan 21 07:37:20 PST 2023
Hi Jaromir,
On 1/20/2023 5:08 PM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> Apologies for my previous message sent prematurely.
>
> Process Browser is checking termination status of all processes very
> often and hence occasionally the procedure gets preempted and breaks
> as you noted in #isDeadOrAtEnd comment. The same happens in my #isDone
> (just open an image and a Process Browser and wait – sooner or later a
> debugger pops up with an MNU error inside #isDone. So, the idea is to
> rewrite #isDone to eliminate message sends at critical points:
>
> isDone
>
> "Answer if the receiver has no unexecuted code left."
>
> ^pc
>
> ifNil: [ true ]
>
> ifNotNil: [ :aPC | (self atEnd: aPC)
> and: [
>
> sender
>
> ifNil:
> [ true ]
>
>
> ifNotNil: [ :ctx | ctx isDone]]]
>
> It’s similar to your #isDeadOrAtEnd.
>
Thanks a lot. This is now at GitHub.
>
> Question: in #isDeadOrAtEnd you have a block [ :aPC | self atEnd: pc
> ]. I wonder if you by any chance meant [ :aPC | self atEnd: aPC ],
> i.e. to use block’s argument rather than the instance variable? Or
> maybe it doesn’t make any difference, I’m just not sure now.
>
It doesn't make any difference in behavior, AFAIK. WRT style, I'm not
really sure which is better. Just looked at the bytecodes of both
options. [ :aPC | self atEnd: aPC ] generates shorter code. I think that
makes it better.
Thanks!
> I hope this time it’s ok.
>
> Best,
>
> Jaromir
>
> *From: *Jaromir Matas via Cuis-dev <mailto:cuis-dev at lists.cuis.st>
> *Sent: *Thursday, January 19, 2023 12:25
> *To: *Juan Vuletich <mailto:juan at cuis.st>; Discussion of Cuis
> Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Jaromir Matas <mailto:mail at jaromir.net>
> *Subject: *Re: [Cuis-dev] Follow-up: #terminate and #suspend update
>
> Hi Juan,
>
> I’ve observed the debugger to pop up all of a sudden a few times when
> working with the Process Browser. The root cause seems to be my
> #isDone method:
>
> isDone
>
> "Answer if the receiver has no unexecuted code left."
>
> self isDead ifTrue: [^true].
>
> self isBottomContext ifTrue: [^self atEnd].
>
> self atEnd ifTrue: [^self sender isDone].
>
> ^false
>
> The second line checks if the sender variable is nil and hence the
> third line assumes the sender is not nil – however it may still be nil
> if the method computation is preempted and the higher priority process
> being checked terminates in the meantime.
>
> Here’s my improved version (also enclosed):
>
> isDone
>
> "Answer if the receiver has no unexecuted code left."
>
> ^sender ifNil: [self isDeadOrAtEnd] ifNotNil: [:ctx |
> ctx isDone]
>
> I think this should work as expected because ifNil:ifNotNil: is
> inlined (not a send).
>
> PS: as a side-effect the ProcessorTest suite now works fine
> consistently; before, some of the tests failed occasionally (on my
> Win10/Intel machine).
>
> Best,
>
> Jaromir
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
> *From: *Juan Vuletich <mailto:juan at cuis.st>
> *Sent: *Tuesday, September 6, 2022 16:25
> *To: *Discussion of Cuis Smalltalk <mailto:cuis-dev at lists.cuis.st>
> *Cc: *Jaromir Matas <mailto:mail at jaromir.net>
> *Subject: *Re: [Cuis-dev] #terminate and #suspend update
>
> Hi Jaromir,
>
> On 8/27/2022 7:12 AM, Jaromir Matas via Cuis-dev wrote:
>
> Hi Juan,
>
> > There is one problem left. #isTerminated will always answer false
> if #suspend primitive failed and old primitive 88 fallback method
> is called. I just pushed to github update #5458 to address this.
> Please check it carefully. Maybe you prefer a different solution,
> I'll be happy to review and integrate it.
>
> Oops, I forgot to mention the backward compatibility consideration
> but you caught it :) (meaning: to be able to run new images with
> older VMs, not only older images with the new VM). Squeak decided
> to maintain only its ability to run older images with the new VM -
> so no change in #isTerminated in Squeak; however I agree with you
> that "fixing" #isTerminated is worth the effort provided the fix
> is pretty easy.
>
> I'm enclosing my original suggestion for #isTerminated; I think
> the semantics is very similar to your version (checking whether
> the remaining context chain has anything useful left) except one
> thing: Your version allows a process with its suspended context's
> pc = nil to be considered not terminated. My understanding was: if
> a process's suspended context's pc is nil, it implies the process
> would be considered terminated. Is this right or would you define
> 'being terminated' differently?
>
> Check this example:
>
> ctx _ [] asContextWithSender: [] asContext.
>
> p _ Process forContext: ctx priority: 40.
>
> ctx pc: nil.
>
> p isTerminated. "answers false in your version and true in mine"
>
> I already noticed a while ago my previous version of #isTerminated
> failed to catch pc = nil in a process's suspended context and
> evaluate the process as 'terminated'. I wonder now what definition
> of 'terminated' state is actually 'the right one'.
>
>
> I had assumed there would always be sender frames. I believe my code
> worked correctly unless there were no sender frames of the frame with
> pc=nil. In any case, your version is more robust and nicer code. I
> just integrated it. Thanks!
>
> Another question: in the example above - how do you look at the
> bytecodes of ctx? In Squeak the Explorer shows the bytecodes right
> away but in Cuis I have to open an extra inspector for 'method'
> and look at 'allBytecodes', right?
>
>
> Yes. You are right. The explorer could be improved, to behave like
> Squeak's in this case. If you happen to have a couple of hours to hack
> this, it would be useful.
>
> In Squeak the process p answers true to #isTerminated even without
> nilling its pc, which is expected because each of the two contexts
> consists only of a single instruction, a return. But in Cuis I'm
> not sure how come the answer is false; I suspect I've got confused
> by the different implementation of Context / ContextPart in
> Squeak/Cuis. Here's what I mean:
>
> ctx _ [] asContextWithSender: [] asContext.
>
> p _ Process forContext: ctx priority: 40.
>
> p isTerminated. "answers false in Cuis and true in Squeak because
> ctx atEnd differs"
>
>
> Just tried the example above, and it answers false in Squeak 6.0 alpha
> 21576 on my Intel Mac. Maybe this has changed recently? Perhaps it
> needs fixing in both environments.
>
> ... while this works the same in both:
>
> ctx _ [1] asContextWithSender: [] asContext.
>
> p _ Process forContext: ctx priority: 40.
>
> p isTerminated. "answers false in both Cuis and Squeak because
> ctx is not atEnd"
>
>
> Yes it does.
>
> Thank you for your advice.
>
> Best regards,
>
> Jaromir
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net <mailto:mail at jaromir.net>
>
>
> Thanks,
>
> --
> Juan Vuletich
> cuis.st
> github.com/jvuletich
> researchgate.net/profile/Juan-Vuletich
> independent.academia.edu/JuanVuletich
> patents.justia.com/inventor/juan-manuel-vuletich
> linkedin.com/in/juan-vuletich-75611b3
> twitter.com/JuanVuletich
>
--
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230121/0a43fba3/attachment-0001.htm>
More information about the Cuis-dev
mailing list