[Vm-dev] OS X Mavericks & cog tickers

[Igor Stasenko]

On 25 October 2013 02:35, John McIntosh <johnmci at smalltalkconsulting.com>wrote:

>
>
>
>
> 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);
>
>
>
.. and along the lines i would also unify time units used by VM,
to get rid of unit conversions everywhere but in primitives/interacting
with OS (which is platform-specific).

:)


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


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20131025/19cb86b8/attachment-0001.htm