On Feb 5, 2008, at 12:51 AM, Andreas Raab wrote:

> 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.

If something could happen it will happen.
Reading the code above now I expect it not to be determinist for p2. I  
admit the first time I expected p2 to get a value.
So now I prefer to have a critical section regarding p2.

I would even wrote the critical section for p1 and p3 since in most of  
the scheduler the code is non determinist.
Especially for p3. The scheduler may not yield the current thread for  
performance reason. (But not in Squeak)

So  I vote for the critical section.


>
>
> Cheers,
>  - Andreas
>

	Mth