Open
Bug 1137128
Opened 9 years ago
Updated 2 years ago
We need a variant of nsITimer that only fires when the process is active
Categories
(Toolkit :: Async Tooling, defect)
Toolkit
Async Tooling
Tracking
()
NEW
People
(Reporter: Yoric, Unassigned)
References
()
Details
Consider a module that needs to poll for information. This can be FHR, add-on CPU monitoring, page memory use monitoring, etc, the profiler, the slow script or slow addon monitor, etc. Currently, the simple solution is to either use a repeating nsITimer on the main thread or spawn a thread and have it sleep, perform its work, then loop. Both solutions wake up Firefox, which is bad for power usage. An ideal solution would automatically activate/deactivate the timer to avoid waking up the process.
Reporter | ||
Comment 1•9 years ago
|
||
A possible algorithm using a thread dedicated to power-safe timers. * Timer Thread 1. Compute next sleep date 2. If no timer active a. Hibernate until awakened by main thread. b. Loop back to 1. 3. Sleep until next date or awakened (to add/remove a timer). 4. If awakened (to add/remove a timer) a. Loop back to 1. 5. Determine how much time has elapsed since we last saw activity from the main thread 6. If main thread is active a. Fire event to target thread. b. Loop back to 1. 7. Otherwise a. Hibernate until awakened by main thread. b. Loop back to 1. * Main Thread In XPConnect's OnProcessNextEvent() 1. Mark the main thread as active In XPConnect's OnAfterProcessNextEvent() 1. Mark the main thread as possibly inactive 2. Update date of latest activity of the main thread * API nsIPowerTimer { init(delay, repeating, nsIEventTarget, nsIRunnable) cancel(); }
Reporter | ||
Comment 2•9 years ago
|
||
Roberto, can you tell me if I'm missing something obvious?
Flags: needinfo?(rvitillo)
Reporter | ||
Comment 3•9 years ago
|
||
More detailed version of the RFC here: https://wiki.mozilla.org/Performance/Power_Timer
Comment 4•9 years ago
|
||
As discussed last week on IRC, the following points need to be addressed: 1) A power friendly variant of nsITimer should exploit OS timer coalescing [1] 2) The current proposal is tied to the behavior of the main-thread, i.e. it assumes that timers shouldn't fire if the main-thread is sleeping. A power friendly variant of nsITimer shouldn't be tied to this specific semantic. Maybe we should file another bug for the more general case? Also note that we have modules that poll information that don't depend only on the main-thread, e.g. BHR. [1] http://en.wikipedia.org/wiki/Timer_coalescing
Flags: needinfo?(rvitillo)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•