J. Vuletich (mail lists) wrote:
> 
> 
> 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.

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