Le dim. 8 mai 2022 à 14:16, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> 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
>
>
About the latest VM, (Smalltalk processSuspensionUnblocks) answers about
the behavior of primitiveSuspend (#88).
The new Behavior is implemented by primitiveSuspendBackingUpV1 (#578) and
primitiveSuspendBackingUpV2 (#588).
V1 always answers the old list (even if a Semaphore/Mutex), V2 answers nil
in case of Semaphore/Mutex.

So, only ((Process>>#suspend) primitive) can give you a clue about the
behavior, assuming that the primitive in question is implemented...

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/e7982c4d/attachment.html>