<div dir="ltr"><div>I have the impression that DelayWaitTimeout depends on the old primitiveSuspend (#88) behavior:</div><div><br></div><div>signalWaitingProcess<br> "Release the given process from the semaphore it is waiting on.<br> This method relies on running at highest priority so that it cannot be preempted<br> by the process being released."<br> beingWaitedOn := false.<br> "Release the process but only if it is still waiting on its original list"<br> process suspendingList == delaySemaphore ifTrue:[<br> expired := true.<br> process suspend; resume.<br> ].<br><br></div><div>My understanding is that this code assumes that suspending, then resuming will remove the waiting process from the list.<br></div><div>So we need a suspendAndUnblock message implemented as <primitive: 88> and indeed need two different primitives.</div><div>Maybe that was the problem encountered by Eliot with virtend? Maybe there are more similar use cases in virtend...</div><div>Up to Eliot to tell.<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 8 mai 2022 à 17:17, Jaromir Matas <<a href="mailto:mail@jaromir.net">mail@jaromir.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" lang="EN-US">
<div class="gmail-m_-2415950077598902453WordSection1">
<p class="MsoNormal">Hi Nicolas,</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">>> About the latest VM, (Smalltalk processSuspensionUnblocks) answers about the behavior of primitiveSuspend (#88).</p>
<p class="MsoNormal">> Err, wrong wording (Smalltalk processSuspensionUnblocks) does not describe the behavior of primitiveSuspend #(88).</p>
<p class="MsoNormal">> It answers whether the VM has primitives #578 and #588 (see #getCogVMFeatureFlags in VMMaker)...</p>
<p class="MsoNormal">><u></u> <u></u></p>
<p class="MsoNormal">Yes, thanks, well that was the original idea for Smalltalk processSuspensionUnblocks to answer about the behavior of the primitiveSuspend #88; which was before the primitives #568 and #578 were introduced. (And which was when I wrote the
tests using this original logic). However that approach ran into problems with some existing implementations (e.g. Virtend) and as a result the two new primitives were introduced (#568 and #578) - and apparently the logic of what Smalltalk processSuspensionUnblocks
answers about changed. Since then I haven't heard from Eliot about his plans how to proceed with the new suspend semantics or whether this is it :)</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In case this is still WIP I'd quite like an approach similar to Smalltalk processPreemptionYields - you'd set Smalltalk processSuspensionUnblocks true or false depending on how you want the VM to behave and the VM would use the right semantics
(unless this is too naive :) ).</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Regarding the tests failing with the newest VM:</p>
<p class="MsoNormal">testAtomicSuspend - we can remove this updated version and leave the existing one for the moment</p>
<p class="MsoNormal">testRevisedSuspendExpectations - we can leave this one out too</p>
<p class="MsoNormal">testTerminateBlockedInNestedEnsure1 - I'll take a look at these two and try to adjust the logic</p>
<p class="MsoNormal">testTerminateBlockedInNestedEnsure2</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">All remaining test in KernelTests-jar.421 work as intended.</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks again,</p>
<p class="MsoNormal">Jaromir</p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="gmail-m_-2415950077598902453MsoNoSpacing"><span lang="CS">--</span></p>
<p class="gmail-m_-2415950077598902453MsoNoSpacing"><strong><span style="font-family:"Calibri Light",sans-serif;color:rgb(51,51,51);font-weight:normal">Jaromír Matas</span></strong><span style="font-family:"Calibri Light",sans-serif;color:rgb(85,85,85)"><u></u><u></u></span></p>
<p class="gmail-m_-2415950077598902453MsoNoSpacing"><span style="font-family:"Calibri Light",sans-serif;color:rgb(46,117,182)"><a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal" style="border:medium none;padding:0in"><b>From: </b><a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">Nicolas Cellier</a><br>
<b>Sent: </b>Sunday, May 8, 2022 16:22<br>
<b>To: </b><a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">The general-purpose Squeak developers list</a><br>
<b>Subject: </b>Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn</p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Le dim. 8 mai 2022 à 15:59, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Le dim. 8 mai 2022 à 14:16, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Hi Jaromir<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Le sam. 7 mai 2022 à 14:45, Jaromir Matas <<a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a>> a écrit :<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Hi Marcel, Nicolas, Eliot,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">> (Nicolas) I have merged Kernel-jar.1446 which is trivial (re-signal an Exception).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks!</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">> (Marcel) Hmm... #testSimpleResignalVsOuter1 is still failing.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In my latest trunk image it passes ok (5/7/22)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">>> (Marcel) I will also take a look at KernelTests-jar.421 to check whether any new semantics are okay.</p>
<p class="MsoNormal">>> </p>
<p class="MsoNormal">> (Nicolas) Yes, I did that and got two failing tests</p>
<p class="MsoNormal">> testTerminateTerminatingProcess</p>
<p class="MsoNormal">> testResumeTerminatingProcess</p>
<p class="MsoNormal">> </p>
<p class="MsoNormal">> both failures look the same, in second self assert: terminator isSuspended.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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: </p>
<p class="MsoNormal">``` self should: [terminatee terminate] raise: Error. ```</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Apologies for the confusion - an updated changeset is enclosed.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.
</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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... </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">Indeed, I can confirm that the latest VM does answer false to (Smalltalk processSuspensionUnblocks).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Though, process suspension still unblocks as shown by the example at<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="https://github.com/pharo-project/pharo/issues/10669" target="_blank">https://github.com/pharo-project/pharo/issues/10669</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">A bit more simply, this answers false - it shouldn't:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">s := Semaphore new.<br>
p := [s wait] newProcess.<br>
p resume.<br>
100 milliSeconds wait.<br>
p suspend; resume.<br>
100 milliSeconds wait.<br>
p isTerminated = Smalltalk processSuspensionUnblocks.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">technically, this answers false - it shouldn't:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">s := Semaphore new.<br>
p := [s wait] newProcess.<br>
p resume.<br>
100 milliSeconds wait.<br>
p suspend == s = Smalltalk processSuspensionUnblocks<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">About the latest VM, (Smalltalk processSuspensionUnblocks) answers about the behavior of primitiveSuspend (#88).<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">Err, wrong wording (Smalltalk processSuspensionUnblocks) does not describe the behavior of primitiveSuspend #(88).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">It answers whether the VM has primitives #578 and #588 (see #getCogVMFeatureFlags in VMMaker)...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">The new Behavior is implemented by primitiveSuspendBackingUpV1 (#578) and primitiveSuspendBackingUpV2 (#588).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">V1 always answers the old list (even if a Semaphore/Mutex), V2 answers nil in case of Semaphore/Mutex.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So, only ((Process>>#suspend) primitive) can give you a clue about the behavior, assuming that the primitive in question is implemented...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">So it depends if we want to make it a Preference, or make the image compatible with some less capable VM...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">we could implement<br>
Process>>primitiveSuspendAndUnblock as <primitive: 88> <br>
Process>>primitiveSuspend as <primitive: 588> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">test the VM flag in suspend<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> Process>>suspend<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> ^(VMHasPrimitiveSuspendBackingUp ifNil: [VMHasPrimitiveSuspendBackingUp := Smalltalk processSuspensionUnblocks not])<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> ifTrue: [self primitiveSuspend]<u></u><u></u></p>
<div>
<p class="MsoNormal"> ifFalse: [self primitiveSuspendAndUnblock]<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Then arrange to reset VMHasPrimitiveSuspendBackingUp to nil at snapshot...<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">I will tell next week about the status of the VM which I used for testing, it's possibly a few months old.<u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">> (Nicolas) I would also consider 1445 1421 and most importantly 1447.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">OK, I will check again.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">> (Marcel) Maybe we can just merge</p>
<p class="MsoNormal">> </p>
<p class="MsoNormal">> KernelTests-jar.393</p>
<p class="MsoNormal">> KernelTests-jar.418</p>
<p class="MsoNormal">> KernelTests-jar.421</p>
<p class="MsoNormal">> </p>
<p class="MsoNormal">> And go from there? Or are there any objections?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">KernelTests-jar.393 is just a special case of a more general KernelTests-jar.418 test…</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In my image all tests are green provided Smalltalk processSuspensionUnblocks answers true and the two above tests Nicolas mentioned are marked expected failures :)</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks very much for your feedback,</p>
<p class="MsoNormal">Jaromir</p>
<p class="MsoNormal"> </p>
<p><span lang="CS">--</span></p>
<p><span style="font-family:"Calibri Light",sans-serif;color:rgb(51,51,51)">Jaromír Matas</span></p>
<p><span style="font-family:"Calibri Light",sans-serif;color:rgb(46,117,182)"><a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a></span></p>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal" style="margin-left:0.2in">
</p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<br>
</blockquote></div>