Hi Jaromir

Le sam. 7 mai 2022 à 14:45, Jaromir Matas <mail at jaromir.net> a écrit :

> Hi Marcel, Nicolas, Eliot,
>
>
>
>
>
> > (Nicolas) I have merged Kernel-jar.1446 which is trivial (re-signal an
> Exception).
>
>
>
> Thanks!
>
>
>
> > (Marcel) Hmm... #testSimpleResignalVsOuter1 is still failing.
>
>
>
> In my latest trunk image it passes ok (5/7/22)
>
>
>
> >> (Marcel) I will also take a look at KernelTests-jar.421 to check
> whether any new semantics are okay.
>
> >>
>
> > (Nicolas) Yes, I did that and got two failing tests
>
> > testTerminateTerminatingProcess
>
> > testResumeTerminatingProcess
>
> >
>
> > both failures look the same, in second self assert: terminator
> isSuspended.
>
>
>
> Yes, they are supposed to fail at the moment so I suggest to make them
> expected failures/feature requests. However there's a stupid bug in both
> I’ve fixed now: they were indeed supposed to fail the following assertion:
>
> ``` self should: [terminatee terminate] raise: Error. ```
>
>
>
> Apologies for the confusion - an updated changeset is enclosed.
>
>
>
>
>
> However, there's another issue regarding the revised #suspend semantics
> Eliot has been working on. I've updated the process tests in
> KernelTests-jar.421 to test both the old and the new #suspend semantics.
> The two semantics should be distinguishable via Smalltalk
> processSuspensionUnblocks flag answering true in case of the old semantics
> and false in case of the revised one; my updated tests use this logic.
> However, unfortunately the latest VM answers "false" but uses the OLD
> suspend semantics in #suspend prim 88.
>
>
>
> So I'm surprised you haven't observed more tests failing due to the new
> suspend semantics... What VM have you used – an older one? I'm on the
> latest trunk's VM 3183. And what is the answer of Smalltalk
> processSuspensionUnblocks? :) I'm utterly confused...
>
>
>
> Hi Eliot - I may be confused here but if the current VM uses the old
> #suspend prim 88 semantics, shouldn't ```Smalltalk
> processSuspensionUnblocks``` answer true?
>
>
>
>
> Indeed, I can confirm that the latest VM does answer false to (Smalltalk
processSuspensionUnblocks).
Though, process suspension still unblocks as shown by the example at
https://github.com/pharo-project/pharo/issues/10669

A bit more simply, this answers false - it shouldn't:

s := Semaphore new.
p := [s wait] newProcess.
p resume.
100 milliSeconds wait.
p suspend; resume.
100 milliSeconds wait.
p isTerminated = Smalltalk processSuspensionUnblocks.

technically, this answers false - it shouldn't:

s := Semaphore new.
p := [s wait] newProcess.
p resume.
100 milliSeconds wait.
p suspend == s = Smalltalk processSuspensionUnblocks

I will tell next week about the status of the VM which I used for testing,
it's possibly a few months old.


> > (Nicolas) I would also consider 1445 1421 and most importantly 1447.
>
>
>
> Regarding 1421: alternatively, you might consider a newer version 1415
> where the only difference is #return:from: passes a block instead of nil to
> #resume:through: to cause a fresh search for the first unwind context;
> otherwise they are equivalent.
>
>
>
OK, I will check again.


> > (Marcel) Maybe we can just merge
>
> >
>
> > KernelTests-jar.393
>
> > KernelTests-jar.418
>
> > KernelTests-jar.421
>
> >
>
> > And go from there? Or are there any objections?
>
>
>
> KernelTests-jar.393 is just a special case of a more general
> KernelTests-jar.418 test…
>
>
>
> In my image all tests are green provided Smalltalk
> processSuspensionUnblocks answers true and the two above tests Nicolas
> mentioned are marked expected failures :)
>
>
>
> Thanks very much for your feedback,
>
> Jaromir
>
>
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220508/46a2ac37/attachment.html>