On Feb 8, 2008, at 2:20 AM, John Brant wrote:

> Mathieu Suen wrote:
>> On Feb 8, 2008, at 12:19 AM, John Brant wrote:
>>> [| 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
>> I am confused why the first fork run before the second fork with  
>> the Andreas patch?
>
> Without the patch, we get the following steps:
> (I've labeled the blocks based on what they output to the shared  
> queue 1, 2, or 3)
> 	A) the 1 block is evaluated at priority lowestPriority + 1
> 	B) the 3 block is forked at priority lowestPriority
> 	C) the 1 block continues to run since it is at a higher priority  
> than the 3 block and it outputs 1 on the queue
> 	D) the 2 block is forked at the same priority as the 1 block and  
> placed on the runnable process list for lowestPriority + 1
> 	E) the 1 block continues to run until it is either interrupted by a  
> higher priority process or it hits the Delay>>wait
> 	F) the 2 block is evaluated since it has a higher priority than the  
> 3 block; this outputs 2 on the queue and terminates
> 	G) if the 1 block was interrupted before getting to Delay>>wait, it  
> resumes and runs to the Delay>>wait
> 	H) the 3 block is evaluated since 2 has terminated and 1 is waiting  
> on the Delay -- it outputs 3 to the queue and terminates
> 	I) finally 1 resumes after the delay, and opens an inspector on the  
> result
>
> With the patch we get (first three steps are the same):
> 	A) the 1 block is evaluated at priority lowestPriority + 1
> 	B) the 3 block is forked at priority lowestPriority
> 	C) the 1 block continues to run since it is at a higher priority  
> than the 3 block and it outputs 1 on the queue
> 	D) a new process for the 2 block is created, but not marked as  
> runnable; another process (2's helper) is forked at priority  
> lowestPriority that will mark 2 as runnable when it runs
> 	E) the 1 block continues to run until it hits the Delay>>wait
> 	F) at this point we have the 3 block and 2's helper process waiting  
> at priority lowestPriority, and 3 is first in the list, so the 3  
> block evaluates putting 3 on the queue and then terminates
> 	G) 2's helper process runs and resumes the 2 block
> 	H) the 2 block runs and outputs 2 on the queue, then it terminates
> 	I) 2's helper terminates
> 	J) finally 1 resumes after the delay, and opens an inspector on the  
> result
>
> BTW, we could get the correct #(1 2 3), if a higher priority process  
> interrupted step F before the 3 was placed on the queue.
>
>


Thanks I was stuck on the fact the #forkAt: have also the patch. So I  
was reasoning with the idea that #forkAt: fork a helper thread.

> John Brant
>

	Mth