We're increasingly using the idle service for deferred tasks, such as expiring old data from databases in the profile. There is also growing interest in moving DB accesses to async IO, in order to avoid locking up the UI. Combined, this could lead to a bit of a problem... If the idle service kicks off notifications to a bunch of observers who are all doing to do heavy async DB I/O, this could cause disk thrashing as multiple queries are launched on independent threads. It's not a huge problem (because the user is supposed to be idle, so they're not around to notice), but it's inefficient and could cause problems for other background tasks on the system. Instead of using NotifyObservers(), the idle service could enumerate the observers and explicitly notify each in turn, waiting for a short interval in between (30 seconds?). Complications to consider include having observers added/removed while iterating the list, and having the system become not-idle while iterating. Maybe both could just be ignored.
I'm assuming you're referring mainly to the daily idle notification as it's the only thing right now that uses NotifyObservers. (The registered listeners get their Observe method directly called, but each one registers their own idle time to get notified at.) Definitely doable by just iterating over nsIObserverService::EnumerateObservers(OBSERVER_TOPIC_IDLE_DAILY) Doing the delay could be with nsITimers and such.. We wouldn't want to spread the delays out too much as the user might get back before each observer finishes as well as delaying too much could spread out activity and prevent battery-powered devices from trying to sleep earlier. But we don't know which listeners are likely to conflict.. Perhaps all listeners get notified within a minute and we randomly pick one to notify every (60 seconds / # listeners)?
You need to log in before you can comment on or make changes to this bug.