[Vm-dev] OS X Mavericks & cog tickers

[John McIntosh]

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

>
>
>
>
> On Thu, Oct 24, 2013 at 4:25 PM, John McIntosh <
> johnmci at smalltalkconsulting.com> wrote:
>
>>
>> Must not hit enter...
>>
>> relinquishProcessorForMicroseconds
>> may or may not one has to find the actual code and maybe it is platform
>> dependent etc etc.
>>
>> An attempt was made to ask the VM what the next wakeup time is. The VM
>> actually knows this it's the bottom end of the Delay logic.
>> We then sleep to this tick, using a call that should awake the process if
>> an BSD interrupt (ill defined) arrives.
>>
>> In here we also service socket handles etc and oh maybe some other house
>> keeping.
>>
>> Still the objective was to sleep until we have to wake up for Morphics 50
>> times a second poll, or some UI/socket/interrupt arrives.
>>
>
> But the objective should be to sleep until theres' something to do:
> - i/o is possible
> - a delay has expired
> - a callback from some other thread has occurred (if the VM is
> multi-threaded)
> Otherwise it should block forever.
>
> This "pause for a little while" is bogus.
>


Well you are guaranteed the next wakeup time from the Delay logic. As the
morphic polling loop is in every squeak based image, that means about 20
milliseconds out.  There is even a 'if' statement to check for zero (never
happens).

the nano sleep() call

nanosleep() function causes the calling thread to sleep for the
     amount of time specified in rqtp (the actual time slept may be longer,
     due to system latencies and possible limitations in the timer
resolution
     of the hardware).  An unmasked signal will cause nanosleep() to
terminate
     the sleep early, regardless of the SA_RESTART value on the interrupting
     signal.

Might waken you on UI or other interrupt activity?




>
>
>>
>> In practice there are some artifacts like the Scheduler saying go to
>> sleep but awake -2 milliseconds ago because of some race condition with in
>> the Delay logic. (good luck finding that)...
>>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 7:18 PM, 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.
>>>
>>>
>>>
>>>
>>> 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
>>>
>>> ===========================================================================
>>>
>>>
>>
>>
>> --
>>
>> ===========================================================================
>> John M. McIntosh <johnmci at smalltalkconsulting.com>
>> Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
>>
>> ===========================================================================
>>
>>
>>
>
>
> --
> 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/69ff874c/attachment.htm