Mantis - Squeak
Viewing Issue Advanced Details
1596 Kernel minor always 08-02-05 17:44 02-24-06 21:41
none 3.9  
0001596: [BUG][FIX] lurking signals in EventSensor
> > > As you mention both processes do this together so nothing
> > > really gets stacked up. However this is needless work...
> PS. Of course it is entirely irrelevant whether a polling loop like
> [Sensor anyButtonPressed] whileFalse.
> busy-loops within the io process or anywhere else. It's the nature of
> polling loops to waste cycles so it really doesn't matter where you
> waste
> them ;-) Note that by your rough estimate it would mean we can run
> approx.
> 10k io process loops per second (I would guess that the real number
> is even
> dramatically higher) so even trying to be a _little_ less agressively
> polling by just waiting a single millisecond would mean we'd reduce
> the load
> on the system by more than 90% ;-)))
> Cheers,
> - Andreas

Ok, I've another version here. It has the pure interrupt driven
subclass, but with a change to
delay for 2 milliseconds any polling activity at the point of doing the
signal semaphore logic, which limits things to <500 calls a second.
Thus doing a boarder stretch doesn't bury the CPU meter.

I considered 2 milliseconds versus 1 millisecond, so other processes
could do work, besides at least on the macintosh the state of the mouse
etc is updated every 16 milliseconds, so looking more often isn't
useful. However I not sure about tablets or the like which might do 300
measurements a second? So I wasn't quite happy with doing say a 5 ms
wait. Certainly I can't tell with a bit of testing any difference
between 2 & 5ms.

Feedback is welcome.
 EventSensorDrivenByVM-JMM.5.cs.gz [^] (1,305 bytes) 08-02-05 17:44
 EventSensorDrivenByVM-JMM.6.cs.gz [^] (1,339 bytes) 08-02-05 17:49
 EventSensorDelayOnHyperPolling.2.cs [^] (2,188 bytes) 11-07-05 23:54

08-02-05 17:47   
John M McIntosh <>:

"Ah, well I was out boating this afternoon and realized that the 2 ms
wait I'v just put into
EventSensor>>nextEventFromQueue isn't a good thing for non-event driven
VM. Thus
I've change the logic to use nextEventFromQueueNoWait.

Attached is a modified changeset."

(attaching EventSensorDrivenByVM-JMM.6.cs.gz)
08-02-05 17:50   
I was able to load both changesets (seperately) without errors. However in both cases once I had done so response to mouse events became quite sluggish. I would estimate something on the order of 500ms delay. I did not test further to try to diagnose the cause however.
11-07-05 21:03   
Seems to collide with work in in 2004 in EventSensor. Will explore why and what the fix should be.
11-08-05 00:04   
EventSensorDelayOnHyperPollling superceeds EventSensorDrivenByVM. Based on decisions made in the summer of 2004 EventSensor was changed to be driven mostly by Morphic. Every 1/50 of second Morphic wakes up and processes events, also every 500 ms a tickler loop wakes up and hunts for pending events. The Event loop then is driven by the morphic world cycle and events from the VM are only read when the world ticks.

This new change set puts in a delay for 2 milliseconds if you attempt to poll for certain values, like keyboard, buttons or position by calling the old non-event driven interface. This change alters CPU usage when resizing browser panes from 90% to 60%, the correct procedure is to obsolete these old interaces and use event drive logic.
02-24-06 21:41   
added to 3.9a7003