nicolas cellier wrote:
> Michael van der Gulik a écrit :
> 
>> Andreas is a great programmer, but the example he posted had a bug in
>> it and the proposed fix was incorrect.
>>
> 
> The patch is correct in its Squeak context.

Unless I've missed some correction to the patch, the patch isn't 
correct. For example, you'll get an "Invalid priority" walkback if you 
try to evaluate the following using the patch:
	[[Transcript show: 'works'; cr; flush] fork]
		forkAt: Processor lowestPriority

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.

[| queue |
queue := SharedQueue new.
[queue nextPut: 3] forkAt: Processor lowestPriority.
queue nextPut: 1.
[queue nextPut: 2] fork.
(Delay forSeconds: 1) wait. "Hack to let the blocks finish"
(Array
	with: queue next
	with: queue next
	with: queue next) inspect] forkAt: Processor lowestPriority + 1


To me, the existing behavior is deterministic. When you fork a process 
at the same priority as the running parent process, then the new forked 
process is added to the list of runnable processes at that priority. The 
parent process continues to run until either a higher priority process 
becomes runnable or it yields control. If a higher priority process 
becomes runnable, then the parent process is suspended and added to the 
end of the runnable processes at its priority. Since it is added at the 
end of the runnable processes list, the forked process will resume 
before the parent resumes.


John Brant