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)

defect

Tracking

()

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.
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();
}
Roberto, can you tell me if I'm missing something obvious?
Flags: needinfo?(rvitillo)
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)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.