[squeak-dev] The Inbox: Kernel-jar.1368.mcz

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 10 20:06:13 UTC 2021


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.


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


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210210/f3482199/attachment.html>


More information about the Squeak-dev mailing list