Hi Eliot,

On Wed, 10 Feb 2021, Eliot Miranda wrote:

> Hi Levente,
> 
> On Wed, Feb 10, 2021 at 11:54 AM Levente Uzonyi <leves at caesar.elte.hu> wrote:
>       On Wed, 10 Feb 2021, Eliot Miranda wrote:
>
>       >
>       >
>       > On Wed, Feb 10, 2021 at 11:27 AM Jaromir <m at jaromir.net> wrote:
>       >       > the right solution is to create a new primitive if we want to support
>       >       on-the-fly priority changes.
>       >
>       >       The system already does on-the-fly priority changes - implementing
>       >       #valueUnpreemptively and #valueAt: - but they're actually not working
>       >       properly due to this #priority: issue - they're trying to use #yield after
>       >       changing the priority down but that really doesn't do anything.
>       >
>       >
>       > So it seems to me that updating the yield primitive to "do the right thing" is a good way to go.  Agreed?  If so, I should be able to get to that very soon.
>
>       I think it's not. Let's say the priority of process p is 30, I want to
>       increase it to 40 and then do something at that priority.
>       #yield will stop the process and put it at the end of the list of
>       processes with 40 priority (I think the current implementation doesn't
>       check for priority changes and puts the process on the list of its
>       earlier priority).
>       So, with yield, p will have to wait until all other 40 priority processes
>       finish their job or yield instead of just continuing as the active
>       process.
> 
> 
> But if that's the behaviour you want you can either
> - set the priority, do the processing, and then invoke yield
> - do the processing and then set the priority and then yield, right?
> 
> We're not tying assigning to priority to the yield primitive, right?  These are still distinct operations.  I'm simply suggesting that the yield primitive take into account the receiver's priority, which it currently doesn't do.

The current issue is that when a process's priority is decreased, e.g. 
from 42 to 40, and there's a process waiting to be executed at priority 
41, then that process will not be activated but the process with priority 
40 will keep on running.
And, even yielding after the priority decrease doesn't help now.

IMO, the ideal solution would be to
1. Make sure that #yield lets all existing higher priority processes run 
besides all the same priority processes.
2. When #priority: is sent to the active process to decrease its priority, 
then that process should
 	a) should keep running without interruption if there's no higher 
priority processes awaiting execution than the new priority
 	b) should be suspended if there are higher priority processes 
ready to run, and it should be resumed once all higher priority processes 
are suspended or terminated.

Only fixing #yield does not help with the requirements in point 2.


Levente

> 
> 
>
>       Levente
>
>       > _,,,^..^,,,_
>       > best, Eliot
>       >
>       >
> 
> 
> 
> --
> _,,,^..^,,,_
> best, Eliot
> 
>