Reset the Mac message pump's delayed work timer upon waking from system sleep

Reset the Mac message pump's delayed work timer upon waking from system sleep.

CFRunLoopTimers are implemented in terms of kernel ticks, a time base which is
suspended while the system is sleeping.  In order to properly perform delayed
work at the proper initially-scheduled time (or at system wake if the
scheduled time passed while the system was asleep), the associated timer needs
to be reset to the most recently scheduled next-fire time on wake from sleep.

BUG=22508
TEST= - Make Chrome the active application.
      - Close all Chrome windows.
      - Close the laptop lid.
      - Wait for it to begin sleeping, indicated by the pulsing light.  NOTE:
        wait until the light actually begins pulsing, not just until it turns
        on.  The disk and fans should all be stopped.
      - Reopen the laptop.  If needed, authenticate to the screen saver.
      - Click the Chrome icon in the dock.  A new window should open on the
        New Tab page.
      - Quickly type "google.com/" into the omnibox.
      - The page should load, its favicon should be visible, and the tab title
        should read "Google".  This should happen as instantly as a normal
        page load.  The tab title should not "stick" on "New Tab" and the icon
        load should not be delayed for any amount of time.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=30335

[Avi (use Gerrit), 2009-10-28 04:25:24]

http://codereview.chromium.org/342011/diff/1/4
File base/message_pump_mac.mm (right):

http://codereview.chromium.org/342011/diff/1/4#newcode110
Line 110: root_power_domain_ = IORegisterForSystemPower(this,
Re QA1340, why not use the Cocoa notification NSWorkspaceDidWakeNotification?

[Mark Mentovai, 2009-10-28 04:33:23]

http://codereview.chromium.org/342011/diff/1/4
File base/message_pump_mac.mm (right):

http://codereview.chromium.org/342011/diff/1/4#newcode110
Line 110: root_power_domain_ = IORegisterForSystemPower(this,
Avi wrote:
> Re QA1340, why not use the Cocoa notification NSWorkspaceDidWakeNotification?

Because I know when we take the kIOMessageSystemWillPowerOn notification.  It
happens before kIOMessageSystemHasPoweredOn.  Several seconds before, in fact. 
I'm not positive of when NSWorkspaceDidWakeNotification is posted, but it seems
like it would hang off of kIOMessageSystemHasPoweredOn.

For this, the sooner we can find out about wake-up, the better.

[TVL, 2009-10-28 11:56:51]

On 2009/10/28 04:33:23, Mark Mentovai wrote:
> http://codereview.chromium.org/342011/diff/1/4
> File base/message_pump_mac.mm (right):
> 
> http://codereview.chromium.org/342011/diff/1/4#newcode110
> Line 110: root_power_domain_ = IORegisterForSystemPower(this,
> Avi wrote:
> > Re QA1340, why not use the Cocoa notification
NSWorkspaceDidWakeNotification?
> 
> Because I know when we take the kIOMessageSystemWillPowerOn notification.  It
> happens before kIOMessageSystemHasPoweredOn.  Several seconds before, in fact.

> I'm not positive of when NSWorkspaceDidWakeNotification is posted, but it
seems
> like it would hang off of kIOMessageSystemHasPoweredOn.
> 
> For this, the sooner we can find out about wake-up, the better.

Actually, don't we need this correction in the browser and renderers?  I'm not
sure the renderers got those notifications since they shouldn't be spinning up
full Cocoa runloops and the sandbox should block the distributed notifications.

[TVL, 2009-10-28 11:58:58]

lgtm

do we also need to worry about issues when the clock shifts based on a time
server for an day light savings transition?

[pink (ping after 24hrs), 2009-10-28 13:46:34]

LGTM

TVL, i remember jgm having similar issues with our metrics uploading in Desktop.
Do you recall if the solution was similar? Also, Mark, did you look at what
Camino does for this? I'm sure it has the exact same problem. Is your solution
here similar?

[TVL, 2009-10-28 13:48:46]

On 2009/10/28 13:46:34, pink wrote:
> LGTM
> 
> TVL, i remember jgm having similar issues with our metrics uploading in
Desktop.
> Do you recall if the solution was similar? Also, Mark, did you look at what
> Camino does for this? I'm sure it has the exact same problem. Is your solution
> here similar?

It was with NSTimers, that was what I went digging for last night and sent Mark
the related pointers that sent us into the CF sources to confirm what
CFRunLoopTimer does.

[pink (ping after 24hrs), 2009-10-28 15:19:11]

On Wed, Oct 28, 2009 at 9:48 AM,  <thomasvl@chromium.org> wrote:
> It was with NSTimers, that was what I went digging for last night and sent
> Mark
> the related pointers that sent us into the CF sources to confirm what
> CFRunLoopTimer does.
>
> http://codereview.chromium.org/342011
>

Five steps ahead of me, as always. Good good.

-- 
Mike Pinkerton
Mac Weenie
pinkerton@google.com