[Pharo-project] Waste of CPU Power by polling events?
eliot.miranda at gmail.com
Fri Nov 26 17:39:41 CET 2010
On Thu, Nov 25, 2010 at 8:25 PM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:
> On 2010-11-23, at 1:23 AM, Henrik Sperre Johansen wrote:
> > On 22.11.2010 22:08, Guido Stepken wrote:
> >> Need additional:
> >> isOnMouseOverEvent
> >> isMouseGestureEvent
> >> isTouchGestureEvent
> > You could try checking out how the iOS code does support for complex
> > It's of course somewhat apple-specific, but hey, would be nice to have
> the same image-side representation and handling of touch-based events if
> Apple is very very notification &event callback oriented in their iOS
> platform. It sleeps until you touch, then you get a touch event, you process
> and go back to sleep. Heck if your startup time takes too many seconds Apple
> nails you.
> For Squeak on iOS I take the touch data place on a queue and signals the
> event semaphore. When the squeak image polls for the event we
> turn the touch data into a complex event and pass it back, then is
> processed by the Smalltalk code to turn into synthetic mouse events. (or
> For keyboard entry, we take the key input data and turn into synthetic
> keystroke events, and again signal the semaphore and put on a queue for
> later when
> the Smalltalk code wakes up and calls getnextevent to see what's up.
> I'm not sure if anyone mentioned the other issue is that the polling loop
> also deals with doing the morphic redrawing so it runs a cycle of doing I
> think it is
> 50 iterations a second.
> For WikiServer which doesn't show a squeak UI I could cut that back to
> doing a cycle every second or so.
> Oh and yet one more thing, the clock tick is yet another issue, some
> platforms assume they can run an interrupt 1000 a second (or more) to ensure
> the VM is responsive to Delay being correctly woken up to the microsecond.
> "PS here I am over simplify the issue & complexity of the issue" but on
> underpowered hardware the issues of how ioRelinquishProcessorForMicroseconds
> and the millisecond timer work become messy issues in relationship to CPU
Yes, we need to change this, but I think one has to change the background
process and/or nothing to run behavior. In the VW VM the VM disables the
heartbeat and enters some blocking call when there's nothing to do. Squeak
runs the background process which calls a primitive that sleeps for a short
time. The former is much better. If a delay is active as the VM does to
sleep it schedules a wakeup event or supplies a timeout so that it blocks
until input is available or the next delay.
We could still keep the background process and do something similar to VW,
disabling the heartbeat until after the relinquish, and factoring the delay
into the relinquish timeout.
Also the heartbeat already has facilities to change its frequency, so one
could modify things to slow down the heartbeat, again ensuring that it ticks
before the next delay expiry.
What approach (not necessarily from the above) appeals to you John?
> John M. McIntosh <johnmci at smalltalkconsulting.com> Twitter:
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project