[squeak-dev] Re: [Vm-dev] [ANN] ARM Stack VMs available
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
** 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
> 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...
>> 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