[Cuis-dev] #terminate and #suspend update

[Juan Vuletich]

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
>
>

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

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