| Anonymous | Login | 10-23-2019 00:39 UTC |
| 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. |  |
