J. Vuletich (mail lists) wrote:
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.
A few times I've seen the idea raised of moving process scheduling into the Image. This sounds interesting. For Pharo** I recently factored the delay scheduling event loop code out from Delay class side to its own DelayScheduler. Now actually I don't see any reason that new class needs to be tied only to Delays. It might also provide process scheduling. Where the VM currently decides which process to run, conceivably the /timingSemepahore/ could be signaled to wake up and decide which process to run next, then call back into the VM to dispatch the selected process. Having process scheduling in the VM would conceivably facilitate development of domain specific process scheduling - e.g. different for interactive UI, web servers, batch processing, robotics, control systems, real-time media. Also this would make a great environment for Computer Science courses to teach process scheduling algorithms. The following looks interesting, although I don't follow all of it... https://computeradventures.wordpress.com/tag/squeak-smalltalk-vm-scheduling/
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...
Less of an issue for Pharo. Maybe this is something to consider for Pharo 5 ? cheers -ben
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...