On Tue, 05 Feb 2008 22:12:37 +0100, Paolo Bonzini <bonzini at gnu.org> 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.  :-(
>
>Paolo
>

I haven't shown any code because VAST and Squeak are different enough in this
area that my #forkReady code would not be helpful but if there is still a race
condition is should be greatly reduced because the #forkReady code puts the
newly created process in the queue of ready processes and returns.  The setting
of the instance variable would have to be interrupted immediately by a task
switch, caused by a timer or some other interrupt.  At least the task switch
would not because by the fork code itself.  Andreas' suggested code looks like
it is trying to delay the task switch to the new process by what seems to me to
be a somewhat convoluted means (sorry Andreas, no offence intended).

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com