I can’t figure out how to transform this one-liner freezing the image into a test:

[] newProcess resume suspendedContext: nil.  "image freezes"

The thing is the undesirable behavior is "image freezes" and I have no idea how to test against this :)

Assigning the suspendedContext seems to need a little more than just a simple setter, like #priority: is not just assigning a value but doing some checking as well.

Thanks,
Jaromir


--

Jaromír Matas

mail at jaromir.net

From: Jaromir Matas<mailto:mail at jaromir.net>
Sent: Wednesday, June 1, 2022 16:49
To: Squeak Dev<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: [squeak-dev] Strange scheduler bug/behavior

Hi,
I've just come across this strange behavior:

Try to execute this (Cmd + . will recover the image):

p := [] newProcess resume. "p placed in run queue"
p suspendedContext: nil.  "image freezes"


This can easily happen when a process gets preempted between the assignment and the next send. The scheduler apparently tries to run the waiting runnable process which has changed its suspendedContext while waiting in the run queue. I sort of expected the scheduler to disqualify such process but it looks like that's not happening.

Changing the suspendedContext while waiting is ok, I guess, as long as the new suspendedContext is a context and most of all is not nil.

I suggest a workaround in Kernel-jar.1474:

suspendedContext: aContext
                suspendedContext := aContext ifNil: [self suspend. nil]

Is this ok?

Thanks,
Jaromir


--

Jaromír Matas

mail at jaromir.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220603/4a204e3b/attachment.html>