On 13 Sep 2015, at 22:11, John McIntosh johnmci@smalltalkconsulting.com wrote:
Hi!
I looked at this six years back and altered the code base to pause the heart beat thread until we know when we have to wakeup .
Results were inclusive, so more testing is welcome.
(a) how much overhead is there to pause and wakeup the thread? If you sleep for 2 ms, is it worth it? (b) because of the morphic polling look we are woken every 16-20 milliseconds. (c) There is a race? between what the VM thinks the next wakeup time, and what the ioRelinquishProcessorForMicroseconds is expected. Sometimes you are asked to sleep, yet the internal VM timer says you should wakeup to service a task right now or a millisecond in the past. Yet the VM had decided there was no runable tasks just microseconds ago.
Thank you for the insight, so depends on the usecase. I don’t know Morphic/WorldState enough to judge if the polling/delay loop is necessary. The usecase I look at is for an image that is mostly waiting for socket i/o (e.g. incoming REST call, TCP command) and the “idle” load is kind of a issue (running 10 images might already fill one CPU core).
Let’s hope i find enough time over the next couple of weeks to work on it for the Unix VM
(d) Do mouse/trackpad/keyboard/socket/FD events actually awake the paused program?
For the X11 code SIGIO is enabled for the XDisplay connection so an event would lead to a wake-up.