#fork and deterministic resumption of the resulting process

John Brant brant at refactoryworkers.com
Fri Feb 8 01:20:07 UTC 2008


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.


John Brant



More information about the Squeak-dev mailing list