[Vm-dev] OS X Mavericks & cog tickers

[John McIntosh]

On Thu, Oct 24, 2013 at 8:32 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
>
> On Thu, Oct 24, 2013 at 5:21 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>>
>>
>> On 24-10-2013, at 5:09 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> >
>> > you mean stepping?
>> > you can signal that semaphore if someone needs to step, as easy as:
>> >
>> > [ [stepTime asDelay wait. sema signal ] repeat ] fork
>> >
>> > (sure not exactly like above, but you got an idea)
>> >
>> > i see no problem here.
>> >
>>
>> That - or something similar, as you say - would provide current morphic
>> behaviour BUT it is really just a way to cause the problem time coalescing
>> is trying to solve.
>>
>> I strongly suspect there is a lot of improvement in Morphic performance
>> that can be gained by making the morphs do smarter (or less) stepping work.
>> Obviously an animated widget is going to want to, well, animate. Almost all
>> widgets to do with text display (editors, lists, buttons) aren't animating.
>> They don't need to step unless there is good reason to think something
>> relevant has changed. As an example, Scratch performance on a Pi took a
>> good step (d'oh, bad pun) forward simply by stopping UpdatingStringMorphs
>> (used for watcher-morphs, for game scores etc) from querying and
>> redisplaying their value every time and instead only re-displaying when the
>> value changed. I suspect here are a lot of cases where we know that some
>> code is going to change state that will then need displays updating and
>> instead of relying on a large number of dumb polling tests we might use an
>> analogue of the old changed/update mvc protocols that *only* advise of a
>> need to step soon.
>>
>
> OK, but these are separable issues.  Making morphs smart enough to know
> they're animated or not, and hence know whether they should be redrawn
> within 50ms or not is completely orthogonal from what the VM should do at
> idle.   When the VM has nothing to do it should sleep until there *is*
> something to do.  One of those things to do is to wake up when the mnext
> delay fires.  So *if* a Morph wants service 50ms from now the VM can still
> sleep until that time.
>
> Can we please stop confusing the conversation and concentrate on the VM's
> bogus idle behaviour.  What we should eb concentrating on now is arranging
> that the VM can enter a fully quiescent idle state that it will exit when
> - i/o is possible (which includes input events, there are a form of "i" in
> "i/o"
> - a signal is delivered (except this could also be a variation of the
> above)
> - the next delay is due to fire
> - a callback has occurred
> I think I'm right in thinking that nothing else can happen that justifies
> the VM leaving its idle state.
>
> Note that in the VisualWorks VM it is the scheduler that enters the idle
> state whenever there is no runnable process, and hence the idle process is
> conspicuously absent.  And a very nice solution that is too.
>


Ok, that would be this code, what clock time is it now, what clock time  do
we have to wake up at?  Sleep until then, or some interrupt.

    now = ioMSecs();
    next = getNextWakeupTick();
    realTimeToWait = next - now;
    aioSleep((int) realTimeToWait*1000);



>
>
>
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Useful random insult:- A kangaroo loose in her top paddock.
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>


-- 
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131024/ce29765e/attachment-0001.htm