Quoting Chris Muller <asqueaker@gmail.com>:
On Fri, Dec 5, 2014 at 11:39 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Juan,
On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" <juanlists@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