2009/5/1 Julian Fitzell <jfitzell at gmail.com>:
> Can I encourage you to submit unit tests for any bugs you find as well
> so they don't regress even if you end up fixing the problem?
>

Certainly, i will.

> Julian
>
> On Fri, May 1, 2009 at 2:14 AM, Igor Stasenko <siguctua at gmail.com> 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]
>>        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.
>>
>> 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.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.