Terry Raymond wrote:
> I think changing the semantics of fork is a way to introduce
> a bug to existing code, i.e. one that is aware of the way
> fork works and relies on it to work that way.

I don't think you (as well as some of the other posters) really 
understand what these changes do. To illustrate:

p1 := p2 := p3 := nil.
p1 := [p1Valid := p1 notNil] forkAt: Processor activePriority-1.
p2 := [p2Valid := p2 notNil] forkAt: Processor activePriority.
p3 := [p3Valid := p3 notNil] forkAt: Processor activePriority+1.

Both, the first and the last case are currently deterministic and will 
stay that way: p1 will be consistently non-nil when this code is run; p3 
will be consistently nil when run. This is currently the case and 
remains the same after applying my changes.

In the second case however, p2 may or may not be nil, depending on 
whether external interrupts occur. Since that is rare, in 99.99+% of all 
cases p2 will be non-nil.

What I am proposing is simply to make p2 non-nil in 100% of the cases. 
There is no change to those parts of the existing semantics that are 
actually well-defined. The only change is that it takes a rare 
non-deterministic occurrence and makes the overall behavior consistent 
in this case.

Cheers,
   - Andreas