Andreas Raab wrote:
> Paolo Bonzini wrote:
>>>> 2) especially, the fix is not 100% safe unless I'm mistaken.
>>>
>>> What do you mean by "100% safe"? It is 100% deterministic (which is 
>>> what I care about); I'm not sure what you mean when you use the term 
>>> "safe" here.
>>
>> It is not. 
> 
> Err, it is not what? Deterministic? Or safe? The point about it being 
> deterministic did not relate to when exactly the process would resume 
> (no real-time guarantee) but rather that it would resume 
> deterministically in relation to its parent process (in this case, only 
> after the parent process got suspended).

I don't have the image in front of me, but what about when the process 
is running at the bottom priority?

What I'm guessing is happening in your case, is that some higher 
priority process is interrupting the "parent" process after it has made 
the forked process runnable, but before it has assigned the variable. 
When the "parent" process is interrupted, it is inserted at the end of 
runnable processes at that priority. Therefore, when the higher priority 
process yields control, instead of yielding control back to the "parent" 
process, it yields control to the forked process.

If my guess is correct and you want deterministic behavior, you could 
change the process scheduler code so that when a higher priority process 
interrupts a lower priority process, the lower priority process is 
inserted at the beginning of the runnable processes at that priority 
instead of the end.

Of course, this change would break the simple time sliced scheduler hack:
	[[(Delay forMilliseconds: timeslice) wait] repeat]
		forkAt: Processor highestPriority
Also, some processes that worked before, might starve now.


John Brant