Quoting Chris Muller <asqueaker at gmail.com>:

> On Fri, Dec 5, 2014 at 11:39 AM, Eliot Miranda  
> <eliot.miranda at gmail.com> wrote:
>>
>> Hi Juan,
>>
>>
>> On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)"
>> <juanlists at jvuletich.org> wrote:
>>
>>> Hi Folks,
>>>
>>> The Squeak process scheduler usually preempts a process only by  
>>> another one of higher priority. And when the scheduler is ready to  
>>> go back at the lower priority, it will always resume the same  
>>> process that was last suspended. The only way for two or more  
>>> processes of the same priority to share the processor is when the  
>>> running process calls #wait or #yield.
>>
>> No.  According to the blue book preempting sends the preempted process
>> to the back if its run queue so preempting forces a yield.  Obviously
>> this is wrong, but that's the way it was defined.  The ObjectWorks &
>> VisualWorks VMs changed this to work as you describe.
>
> Why is that wrong?  By sending it to the back, one gets task-switching
> that acts like real "multitasking" as one would expect in a real
> multitasking system, without the developer having to put in explicit
> sends to #yield.  Keeping it at the front "enables" multi-processing
> code to be developed incorrectly so that, one day, when it might ever
> get to a real multitasking environment, it won't work and it'll be
> harder to debug since by then its old and probably more complex.
> #yield is not a good synchronization tool..

Well, yes. But for that to work we'd need a highest priority process  
that keeps sleeping for, lets say, 1 mSec, and does nothing. That way  
all processes would be suspended and shuffled all the time.

The way it is right now, this shuffling won't happen often, and  
("bad") code that assumes the behavior I described would work "most of  
the time", breaking randomly, and more often on slower hardware (such  
as the PI)...

Is this worth doing? This "bad" code would fail all the time, and it  
would be spotted and fixed. But we would break (a rather illusory)  
back compatibility... For instance, the code Ken is using for  
animating the game cards (moving morphs around in a separate process)  
would break for sure. But fixing it would also fix the issues he sees  
on the PI. It is not hard to imagine that the same would happen to the  
sound problems Tim found on Scratch on the PI...

Cheers,
Juan Vuletich