#fork and deterministic resumption of the resulting process
Mathieu Suen
mathk.sue at gmail.com
Fri Feb 8 01:55:21 UTC 2008
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
More information about the Squeak-dev
mailing list
|