#fork and deterministic resumption of the resulting process

Igor Stasenko siguctua at gmail.com
Fri Feb 8 04:42:23 UTC 2008


On 08/02/2008, Michael van der Gulik <mikevdg at gmail.com> wrote:
>
>
>
> On Feb 8, 2008 1:32 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:
> >
> > >      Yes, the #lowestPriority case would be a problem.  The
> > >     #lowestPriority would be renamed to #reallyLowestPriority and new
> > >     #lowestPriority would return #reallyLowestPriority+1?
> > >
> > > Would you seriously consider changing this in the squeak.org image?
> >
> >  I don't know the right answer to this question.  I understand that
> > most of people don't need it and then don't want to have it.  OTOH, I
> > don't mind to have it and that would prevent a few people in the
> > future stumble on the problem...
> >
>
>
> In that case, the lowest priority idle thread needs to be of a lower
> priority than #reallyLowestPriority, so I propose also adding
> #actualReallyLowestPriority to be the lowest priority, then
> #reallyLowestPriority to be #actualReallyLowestPriority+1 and
> #lowestPriority to be #actualReallyLowestPriority+2.
>
>

I'd like to run this code:

block := [:counter |
       counter > 0 ifTrue: [
            [ block value: counter -1 ] forkAt: (Processor currentPriority -1 )
      ]
  ].

block value:1000.

In result it should spawn 1000 processes climbing down priority levels.

Just want to note, that if we using relative priority values , then we
should care that given example will work, and get rid of the absolute
priority values.
Processor lowestPriority then should mean the process which running
with lowest priority.
And so, you can schedule new process with even lower priority, if you like so.
Same for the #highestPriority - it should be a highest known value of
priority which used by running processes.


> Gulik.
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list