#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