#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