[Vm-dev] Stack Cog and Heartbeat

[John McIntosh]

Allow me to give some more knowledge as I struggled with this for a
decade or so.

Now I believe in VW as I looked last week for another reason is that
when a yield happens it appears to want to run the next best process.
That can lead to no process runnable so it then waits for an interrupt
which can be from a timer, or socket, file, ui etc...  Then the VW is
woken to service that

Now in Squeak we had

ioRelinquishProcessorForMicroseconds
which is run as the lowest priority process and basically means go to
sleep. So how long?
Good questions. Well a decade back that was some magic number that had
no bearing on reality plus the non-real-time linux system might sleep
for 100 ms, bad..

Anyway that evolved over time and the first bread crumb is...

getNextWakeupTick()

That is the next known time from the Delay logic to wake up the VM to
service a Delay.

If you rummage around a bit you'll find time now - getNextWakeupTick()
could be in the future, could be zero, could be slightly in the past.
You need to handle all cases.
BTW I know that sometimes it can be now, but the Smaltlalk code isn't
quite ready to make the Delay run able so you might get 50 calls
saying delay fires now or in the past, but we are idle.... Bonus
points if you can figure out why..

Bread crumb two, In the past Morphic was responsible for pounding the
VM every 1/60 or so polling for UI events.  But In the current Pharo
version this has been fixed which led to a problem with the Mac VM not
sufficiently polling for UI events, see bread crumb three.


Bred crumb three, some VM's need time to service/poll I/O this was
done by stuff that Eliot mentioned earlier which based on interpreter
code running would vary in the call times, also see two and I can't
recall with Esteban and I did to fix the issue.

(4) If the VM is sleeping why fire the heartbeat. I looked at this but
with morphic firing every 12-16 ms the cost of fixing up the thread
was more expensive from a CPU time than not doing it.  But this should
be revisted now that Pharo doesn't poll every 12 ms, all I did was
suspend the pthread, resume. But maybe you can alter the delay time?
Mmm set the next timer fire to be 234 ms out as that is the next fire
time for the Delay, if we get an interrupt then resume the clock.


-- 
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================