Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001596 [Squeak] Kernel minor always 08-02-05 17:44 02-24-06 21:41
Reporter johnmci View Status public  
Assigned To
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0001596: [BUG][FIX] lurking signals in EventSensor
Description > > > 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.
Additional Information
Attached Files  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

- Relationships

- Notes
(0002082 - 361 - 443 - 480 - 480 - 480 - 480)
KenCausey
08-02-05 17:47

 John M McIntosh <johnmci@mac.com>:

"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)
 
(0002083 - 272 - 272 - 272 - 272 - 272 - 272)
KenCausey
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.
 
(0003043 - 98 - 98 - 98 - 98 - 98 - 98)
johnmci
11-07-05 21:03

 Seems to collide with work in in 2004 in EventSensor. Will explore why and what the fix should be.
 
(0003044 - 760 - 772 - 772 - 772 - 772 - 772)
johnmci
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.
 
(0004065 - 17 - 17 - 17 - 17 - 17 - 17)
MarcusDenker
02-24-06 21:41

 added to 3.9a7003
 

- Issue History
Date Modified Username Field Change
08-02-05 17:44 KenCausey New Issue
08-02-05 17:44 KenCausey File Added: EventSensorDrivenByVM-JMM.5.cs.gz
08-02-05 17:45 KenCausey Reporter KenCausey => johnmci
08-02-05 17:47 KenCausey Note Added: 0002082
08-02-05 17:49 KenCausey File Added: EventSensorDrivenByVM-JMM.6.cs.gz
08-02-05 17:50 KenCausey Note Added: 0002083
11-07-05 21:03 johnmci Note Added: 0003043
11-07-05 23:54 johnmci File Added: EventSensorDelayOnHyperPolling.2.cs
11-08-05 00:04 johnmci Note Added: 0003044
02-24-06 21:41 MarcusDenker Status new => closed
02-24-06 21:41 MarcusDenker Note Added: 0004065
02-24-06 21:41 MarcusDenker Resolution open => fixed
02-24-06 21:41 MarcusDenker Fixed in Version  => 3.9

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
59 total queries executed.
40 unique queries executed.
Powered by Mantis Bugtracker