Hi Nicolas, Eliot,

> Hi Eliot,
>
> > Le lun. 9 mai 2022 à 20:36, Eliot Miranda <eliot.miranda at gmail.com> a écrit :
> > Hi Jaromir, Hi Nicolas,
> >
> > On Sun, May 8, 2022 at 8:17 AM Jaromir Matas <mail at jaromir.net> wrote:
> > Hi Nicolas,
> >
> > >> 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)...
> > >
> > 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 :)
> >
> > Apologies for not responding sooner.  It seems to me the semantics must remain as they are, and it be left up to the image to bind suspend to the primitive most convenient. Then backwards compatibility can be provided for cases such as DelayWaitTimeout by providing a renamed suspend which accesses the old primitive.

Thanks a lot for clarification.

>
> Yes, I propose the selector
> Process>>suspendAndUnblock <primitive: 78> snip...
> Process>>suspend would call the new primitive, and fallback to suspendAndUnblock in case of failure (for example if new primitive is absent).
> The question remaining is if we really need two new primitives 578 (V1) and 588 (V2).
> It seems like signalException: would require V1, while Jaromir terminate logic would require V2...

Two comments:

1) the new primitives are 568 (V1) and 578 (V2) (not 588... I hope I'm right)
2) my latest terminate logic is independent of the suspend primitive used; it works for all three alternatives (the latest being Kernel-jar.1447)

> > Sorry about not renaming processSuspensionUnblocks.  This should be something like Smalltalk hasExtendedProcessSuspensionSemantics or some such.
>
> It's not too late, there are not many usages, except inbox experimentations.

Best ,
Jaromir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220509/e472f558/attachment-0001.html>