Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Aha. So wakeHighestPriority is a rather convenient way (and a case of method re-use) to realize the desired behavior of yield. We assume that "highest priority" is of no concern when calling this method but only to let the next process on the same priority run. This led me to false conclusions about how things are expected to work. Maybe we want to comment the use of wakeHighestPriority in primitiveYield to avoid such confusion in the future.
(Btw: The timestamps of primitiveYield are weird in CoInterpreterPrimitives and InterpreterPrimitives, namely "eem 3/2/-4654 00:12" and "eem 3/2/-4654 00:02".)
Yes, it would be nice to expose wakeHighestPriority (or something similar) as primitive to complement priority changes from within the image. In the meantime, TimingSemaphore signal (see Delay class) could be a feasible workaround as Leon suggested:
Delay class >> wakeHighestPriority
"Helper to fix scheduling after the active process changed its own priority."
TimingSemaphore signal.
Process >> priority: anInteger
"Set the receiver's priority to anInteger."
(anInteger >= Processor lowestPriority and:[anInteger <= Processor highestPriority])
ifTrue: [priority := anInteger. Delay wakeHighestPriority]
ifFalse: [self error: 'Invalid priority: ', anInteger printString].Any concerns?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.