#fork and deterministic resumption of the resulting process
Joshua Gargus
schwa at fastmail.us
Tue Feb 5 22:57:35 UTC 2008
On Feb 5, 2008, at 1:12 PM, Paolo Bonzini wrote:
>
>> I ran into a similar problem in VAST that I got around by extending
>> Block and
>> Process. I extended Block with #forkReady, #forkReadyAt: and some
>> others and
>> Process with #ready. The #forkReady extension to Block basically
>> does what it
>> says, it creates a new fork or process in the ready state by does
>> not start it
>> immediately. The new process will wait for its normal turn to
>> start. The
>> #ready extension to Process makes the process ready without running
>> it
>> immediately and is used by #forkReady.
>
> I bet that your #forkReady has the same race condition problem that
> Andreas is trying to solve in Squeak's #fork. :-(
I think you misunderstand (unless I misunderstand)... it sounds like
the Process created by #forkReady doesn't start until explicitly
resumed:
worker := [self workerLoop] forkReady.
worker resume.
Also, Andreas is not trying to solve a race condition (for example,
the race condition still exists if you fork at a higher priority).
He's just trying to make it deterministic: make it either work all the
time (as with forking a lower-priority process, or with Andreas's
patch, a process of the same priority), or fail all of the time (as
with forking a higher-priority process). This makes it easier to
debug than having something that works 9999 times out of 10000.
Josh
>
>
> Paolo
>
More information about the Squeak-dev
mailing list
|