I may be completely off but let me ask you this:
How a process coming down from a higher priority should be treated:

(A) as a 'regular' process trying to run at a given priority - i.e. send it
to the back of the queue
(B) as a sort of 'privileged' process deserving the front of the queue, as
if previously 'preempted' by itself

Now, as I can see only two usage examples - #valueUnpreemptively and
#valueAt, the question is how are these two supposed to work ideally? At the
moment they behave - or rather were supposed to I guess - like (A) and
changing #yield implementation and using it in the #priority: method would
preserve the (A) behavior.

However, I wouldn't rule out behavior (B) because it would provide a nice
choice based on #processPreemptionYields setting:
- for `false` (default) the active process wouldn't yield and "stay" at the
front of the queue and
- for `true` the active process would yield and go to the end of the queue.
For this scenario something like`[ ] forkAt: Processor highestPriority` in
the #priority would provide such behavior.

To illustrate such scenario I propose the following test:
- currently it fails as the val assignment never happens...

testPriority
	"test whether #priority: preempts active process to allow higher priority
processes run;
	#priority behavior reflects the processPreemptionYields setting - for false
(default)
	the active process gets to the front of the queue while for true it goes to
the end"

        | val oldPriority |
        val := nil.
        oldPriority := Processor activePriority.
        Processor activeProcess priority: oldPriority + 2.
        [ val := false ] forkAt: oldPriority + 1.
        [ val := true ] forkAt: oldPriority.
        Processor activeProcess priority: oldPriority.
        self assert: val equals: Smalltalk vm processPreemptionYields

Sorry for the lengthy message... Thanks



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