On Fri, 01 May 2009 11:14:02 +0200, Igor Stasenko wrote:

> Here the test, showing that setting a priority of preempted process
> may not result of what you expected:
>
> | first p1 p2 |
> first := nil.
> p1 := [ first ifNil: [ first:= 1] ] forkAt: Processor activePriority - 1.
> p2 := [ first ifNil: [ first:= 2] ] forkAt: Processor activePriority - 2.
> p1 priority: 10.
> (Delay forMilliseconds: 100) wait.
> first
>
> at first, an order in which processes should awake is p1 then p2.
> But then, if we setting p1 priority lower than p2 , the order should
> be p2 then p1.
>
> To fix this we should reschedule preempted process:
>
> Process>>priority: anInteger
> (anInteger >= Processor lowestPriority and:[anInteger <= Processor
> highestPriority])
> 	ifTrue: [priority := anInteger]

Awesome, this block with assigning priority together with [^ self] below  
:) if scheduler ever sees this guy again it will DoTheRightThing :)

> 	ifFalse: [self error: 'Invalid priority: ', anInteger printString]
> (myList isNil or: [myList class == Semaphore]) ifTrue: [ ^ self  ].
> "we are preempted. reschedule at new priority"
> self suspend;resume.

Is there anything being able to disturb (self suspend;resume),  
non-atomically, from what you can see?

> This issue shows, that comment in Process>>#terminate, lying to us:
>
> "Since the receiver is not the active process, drop its priority to
> rock-bottom so that

:(

> it doesn't accidentally preempt the process that is trying to terminate  
> it."
> priority := 10.