>  looking at the valueUnpreemptively
> method the Processor yield was meant to let the same priority preempted
> processes a chance to run

Not quite. If you are at 40 and get boosted up to 80, there can be preempted processes at any other priority in between. I would expect that "Processor yield" accounts for that. Other processes running at 40 do not matter because we have cooperative schedulding at each priority.

Best,
Marcel
Am 02.02.2021 15:18:15 schrieb jaromir <m at jaromir.net>:
> Not sure whether this is "by design" or actually a bug... most of the time,
you would not need "Processor yield" to also look for interrupts. There are
typically enough other suspension points. Hmmmm...

Aaah, I guess I know what you mean - looking at the valueUnpreemptively
method the Processor yield was meant to let the same priority preempted
processes a chance to run but here we have a higher priority process
scheduled and yield doesn't look there. And when you change `activeProcess
priority: oldPriority` just like this there's a higher priority process
scheduled while a lower priority process running! Funny, I thought that
can't happen :D

valueUnpreemptively
| activeProcess oldPriority result |
activeProcess := Processor activeProcess.
oldPriority := activeProcess priority.
activeProcess priority: Processor highestPriority.
result := self ensure: [activeProcess priority: oldPriority].
"Yield after restoring priority to give the preempted processes a chance to
run"
Processor yield. "<-- replace by:
[activeProcess resume] fork.
activeProcess suspend."
^result

I wanted to suggest replacing the yield as above but it may be a more
general issue...

J



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210202/029342f5/attachment.html>