#fork and deterministic resumption of the resulting process
Joshua Gargus
schwa at fastmail.us
Tue Feb 5 23:02:15 UTC 2008
On Feb 5, 2008, at 2:57 PM, Joshua Gargus wrote:
>
> 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:
I'm wrong again, I misunderstood how #forkReady is supposed to work.
I don't know how the VAST scheduler works, so maybe there is no race-
condition, but it sounds very similar to the Squeak race-condition
that we're talking about.
I should really stop posting on this topic.
Josh
>>
>>
>> Paolo
>>
>
>
More information about the Squeak-dev
mailing list
|