#fork and deterministic resumption of the resulting process

>
>
> > Paolo> Without the patch *and with any scheduler that executes same-priority
> > Paolo> processes fairly* the program is ensured to finish.  With the patch, the
> > Paolo> program might not finish.  The two producer processes might ping-pong control
> > Paolo> to each other, and the delay won't even be started.
> >
> > A workaround that handles badly written beginner code but eventually
> > ruins the semantics for properly written expert code doesn't sound
> > very good.  It's like ensuring that every motorcycle sold automatically
> > comes with training wheels.  Ouch.
>
> I wasn't saying that my code is practical or well written -- it's just
> that I can prove it finishes.  But indeed your motorcycle metaphor is
> what I was trying to say.

> And some notes about priority.
>  I don't know much details how current squeak scheduler arranging things,
>  i'm just want to point out, that you using relative priority in your
>  samples and in your proposed patch, by writing  Processor
>  activePriority +/- n.
>  This, in own turn uncovers another problem with current scheduler
>  implementation: it's not designed to use relative priorities in mind.
>  As people pointed out:
>  Processor highestPriority + 1
>  or:
>  Processor lowestPriority -1
>  makes no sense, and lead to errors or unpredicted behavior.
>  So, first, i think, that if you really want to use relative priority
>  values, you should make changes to current implementation do to it
>  well and without errors.
>
>  Now, let's say if you make thing in the way, as i proposed in post
>  before (use highest/lowest priorities to depend only from current set
>  of running processes), the only thing which is left is to introduce a
>  scale.
>  I proposing a logarithmic time slicing:
>  a process with priority N doing roughly twice as much operations as
>  process with priority N-1 for a given period of time.