[squeak-dev] Re: [Vm-dev] [ANN] ARM Stack VMs available

Ben Coman btc at openInWorld.com
Sun Dec 7 10:55:27 UTC 2014


Ben Coman wrote:
> 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.  


** I forgot to say, once its been proven in Pharo, I'd be happy to do 
the same for Squeak - if there is interest.  Among other things it gets 
rid of the Delay clock rollover every six days.  I don't think there has 
been much divergence in this area and it would be good to keep in sync 
if possible.
cheers -ben


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


More information about the Squeak-dev mailing list