#fork and deterministic resumption of the resulting process
John Brant
brant at refactoryworkers.com
Fri Feb 8 01:51:06 UTC 2008
Yoshiki Ohshima wrote:
>> Furthermore, it allows lower priority processes to run before a process
>> forked at a higher priority. For example, here's an example, that should
>> open an inspector on #(1 2 3), but with the patch, it opens on inspector
>> on #(1 3 2). The process forked at the lowest priority is run before the
>> one forked at a higher priority.
>
> It depends on the interpretation of "should" above. So, one of
> points sig and Michael made was that in the future we may have
> parallel-processing VM and a different scheduler. In that case, a
> process with higher priority would mean that it gets scheduled more
> often than lower one, but not necessarily it prevents a lower one from
> running, right? If we take that variation of scheduler into account,
> "nextPut: 3" may be scheduled before nextPut: 3 and it is not
> "incorrect". (From one point of view, a program that relies on a
> particular implementation of scheduling is wrong.)
If we consider a parallel-processing VM, then Andreas' patch won't come
close to working, since it won't guarantee that the forked process isn't
started too early. Therefore, I wasn't considering a parallel processing
scheduler. However, I think my statement is true for the current
schedulers in VW, VA, Dolphin, and Squeak. All of them have a variation
of a scheduler that has only a single active process and implements this
rule:
active process' priority >= all runnable processes' priorities
John Brant
More information about the Squeak-dev
mailing list
|