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
>