>> Not completely deterministic.  The behavior may change depending on 
>> whether there are other processes or not, that run at the active 
>> process priority.
> 
> It is entirely deterministic in such that the forked process will not be 
> resumed until the parent process is suspended. No amount of other 
> processes change that; even if they take 100% CPU it won't change the 
> fact that the process will not be resumed before its parent is suspended.

I'm talking about starvation, due to the forked process not entering 
Squeak's round-robin scheduling at the given priority.  It cannot happen 
without your patch, and can with.

>> What if you instead bumped a little the priority of the active process 
>> until the forked process started running?
> 
> And how does the parent process know that the forked process is running?

The forked process could reset the priority of the parent process:

fork
     ^self forkAt: (Processor activePriority bitAnd: -2)

forkAt: priority
     Processor activePriority = priority ifTrue: [
         p := Processor activeProcess.
         p priority: (priority bitOr: 1).
         forkedProcess :=
             [p priority = (priority bitOr: 1)
                 ifTrue: [p priority: priority].
             self value] newProcess.
     ] ifFalse: [
         forkedProcess := self newProcess
     ].
     forkedProcess priority: priority.
     forkedProcess resume.
     ^forkedProcess

Maybe this causes a different kind of race condition though.

Paolo