#fork and deterministic resumption of the resulting process
John Brant
brant at refactoryworkers.com
Thu Feb 7 23:19:57 UTC 2008
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
More information about the Squeak-dev
mailing list
|