[Vm-dev] OS X Mavericks & cog tickers

John McIntosh johnmci at smalltalkconsulting.com
Thu Oct 24 23:39:59 UTC 2013


After you solve aioPoll()

You could consider waiting in the morphic polling loop until a VM UI event
interrupt comes in, or to when you need to wake up to service your Morphic
responsibilities.


On Thu, Oct 24, 2013 at 7:34 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
>
>
>
> On 25 October 2013 01:18, John McIntosh <johnmci at smalltalkconsulting.com>wrote:
>
>>
>> Well let me reflect.
>> Nothing has changed, the VM energy sapping field is the same as
>>  yesterday, just more evident.
>>
>>  I wasn't able to determine what code base is used, but if I go back 5 or
>> 10 years.
>>
>> (a) The morphic event polling cycle runs 50 times a second. One could
>> write some timer consolidation code there to consider when do I have to
>> wake up and paint all those morphs? No C/Objective-C/assembler/fortran
>> required...
>>
>> (b) Maybe the VMs are event driven now and Morphic does not need to poll
>> 50 times a second?
>>
>> (c) The BSD Unix socket system requires polling of some form.  But see
>> work by Craig 10-15 back on "Flow"
>>
>> (d) When all the Smalltalk Processes settle, the dispatcher runs the
>> lowest priority task which calls relinquishProcessorForMicroseconds with
>> a bogus value.
>>
>>
> (e) Cog uses heartbeat timer to interrupt interpreter at regular time
> periods
> what can be done, i think it to suppress heartbeat, during
> relinquishProcessorForMicroseconds execution.
> but that won't buy much, unless we increase the time period to sleep to be
> times larger than heartbeat cycle (both are 1ms).
>
> sqMacV2Time.c:
>
> sqInt ioRelinquishProcessorForMicroseconds(sqInt microSeconds) {
>     //API Documented
>     /* This operation is platform dependent.      */
>     #pragma unused(microSeconds)
>
>     sqInt       realTimeToWait,now,next;
>     extern sqInt getNextWakeupTick(void);                //This is a VM
> Callback
>     extern sqInt setInterruptCheckCounter(sqInt value);  //This is a VM
> Callback
>
>     setInterruptCheckCounter(0);
>     now = ioMSecs();
>     next = getNextWakeupTick();
>
>     /*BUG??? what if clock wraps? */
>
>     if (next <= now)
>         if (next == 0)
>                 realTimeToWait = 16;
>             else {
>                 return 0;
>             }
>         else
>             realTimeToWait = next - now;
>
>     aioSleep((int) realTimeToWait*1000);
>     return 0;
> }
>
>
> The real solution would be to not fall asleep,
> but just put process into waitable state on 'wake up semaphore'
> which then signaled if there's some i/o or timeout.
>
>
>>
>>
>> On Thu, Oct 24, 2013 at 6:21 PM, tim Rowledge <tim at rowledge.org> wrote:
>>
>>>
>>> Looking through some of the low-level changes in Mavericks I noticed
>>> stuff about timer consolidation. I *think* that it is something that you
>>> can offer to allow, rather than something done unto you code, but almost
>>> certainly it will have some sort of impact on the heartbeat ticker type of
>>> code used in stackvm/cog. Where is a skilled Mac vm maintainer when you
>>> need one?
>>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin
>>>
>>>
>>>
>>
>>
>> --
>>
>> ===========================================================================
>> John M. McIntosh <johnmci at smalltalkconsulting.com>
>> Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
>>
>> ===========================================================================
>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>


-- 
===========================================================================
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/3e8a3bf4/attachment.htm


More information about the Vm-dev mailing list