Hi Eliot, all,

I'm back to my original question what is the *desirable* semantics of #resume and #suspend for Squeak:

We’ve discussed #suspend and you’ve implemented the very elegant backing of the blocked process before the send wait.

Now we have this unexpected #resume behavior plainly letting a process continue regardless of whether it’s being blocked.

I’ve checked VW and VA:

VW’s #suspend removes the process from the conditional variable’s list and #resume fails an attempt to resume a blocked process. The examples below behave as expected.

VA on the other hand treat blocked processes equally as suspended processes which seems to me as if they ignored/redefined the idea of conditional variables; i.e. suspending a blocked process is a no-op and resuming a blocked process simply removes it from the semaphore and puts it in the runnable list.

It seems to me Squeak sits inconsistently somewhere in-between. From #resume and #suspend comments being identical to VW’s I guess VW’s behavior was the original intention.

best, ~~~ ^[^ Jaromir

From: Jaromir Matasmailto:mail@jaromir.net Sent: Thursday, January 13, 2022 19:29 To: vm-dev@lists.squeakfoundation.orgmailto:vm-dev@lists.squeakfoundation.org; Eliot Mirandamailto:eliot.miranda@gmail.com Subject: Unexpected #resume behavior

Hi Eliot, all,

I'm baffled by this example:

p := [Semaphore new wait] fork. Processor yield. p resume explore

I expected to get an error but the process just gets out of the semaphore and finishes happily.

#resume comment says: Primitive. Allow the process that the receiver represents to continue. Put the receiver in line to become the activeProcess. *Fail if the receiver is already waiting in a queue (in a Semaphore or ProcessScheduler)*. Fail if the receiver's suspendedContext is not a context.

The following works as expected - p sits at the semaphore:

p := [Semaphore new wait] fork. Processor yield. p explore

This works as well (with the new VM) - p backs up and sits before the wait:

p := [Semaphore new wait] fork. Processor yield. p suspend. p explore

And this works too indeed - p sits at the semaphore again after suspend.

p := [Semaphore new wait] fork. Processor yield. p suspend. p resume explore

Is this a bug? Or is the comment just outdated?

I've been trying to figure out possible ways how to prevent resuming a process being terminated (other than setting its suspendedContext to nil) and this unexpected behavior gave me a real hard time :)

Many thanks for your help.

Best regards, Jaromir