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

>
>
> 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).
>
Err,  wrong wording (Smalltalk processSuspensionUnblocks) does not describe
the behavior of primitiveSuspend #(88).
It answers whether the VM has primitives #578 and #588 (see
#getCogVMFeatureFlags in VMMaker)...

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...
>
> So it depends if we want to make it a Preference, or make the image
compatible with some less capable VM...

we could implement
    Process>>primitiveSuspendAndUnblock as <primitive: 88>
    Process>>primitiveSuspend as <primitive: 588>
test the VM flag in suspend
    Process>>suspend
        ^(VMHasPrimitiveSuspendBackingUp ifNil:
[VMHasPrimitiveSuspendBackingUp := Smalltalk processSuspensionUnblocks not])
            ifTrue: [self primitiveSuspend]
            ifFalse: [self primitiveSuspendAndUnblock]
Then arrange to reset VMHasPrimitiveSuspendBackingUp to nil at snapshot...

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