Bug 240359

Summary: Monitor process state and send prepareToSuspend based on that
Product: WebKit Reporter: Sihui Liu <sihui_liu>
Component: New BugsAssignee: Sihui Liu <sihui_liu>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, ggaren, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch ews-feeder: commit-queue-

Description Sihui Liu 2022-05-12 13:42:49 PDT
...
Comment 1 Sihui Liu 2022-05-12 14:36:14 PDT
Created attachment 459251 [details]
Patch
Comment 2 Sihui Liu 2022-05-13 09:31:06 PDT
Created attachment 459306 [details]
Patch
Comment 3 Geoffrey Garen 2022-05-13 15:37:58 PDT
Comment on attachment 459306 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=459306&action=review

Looks right to me. Probably want Chris to review too, since we came up with this together.

> Source/WebKit/UIProcess/ios/ProcessStateMonitor.h:50
> +    State m_state { State::Unknown };

Do we need the Unknown state or can we just start out Running or Suspended? Maybe Running?
Comment 4 Chris Dumez 2022-05-13 16:10:51 PDT
Comment on attachment 459306 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=459306&action=review

> Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:1071
> +    for (auto& process : m_processes)

This function needs RELEASE_LOGGING

> Source/WebKit/UIProcess/ProcessThrottler.cpp:64
> +        ASSERT(m_backgroundActivities.isEmpty());

If the BackgroundActivity is not quiet, I think we should RELEASE_LOG() that we refused to start it.

> Source/WebKit/UIProcess/ProcessThrottler.cpp:265
> +void ProcessThrottler::setAllowBackgroundActivity(bool allow)

I don't understand this logic, so you're preventing clients from taking background activities but not foreground ones? Why?
Seems like they can extend the assertion forever if they can keep taking foreground assertions.

> Source/WebKit/UIProcess/ProcessThrottler.cpp:269
> +

This function needs RELEASE_LOGGING

> Source/WebKit/UIProcess/WebProcessProxy.h:440
> +    void setShouldSuspend(bool);

We probably don't need this setter. The call site can probably just use WebProcessProxy::throttler().setAllowBackgroundActivity(() instead.

> Source/WebKit/UIProcess/ios/ProcessAssertionIOS.mm:98
> +        if (m_processStateMonitor)

We don't need this check.

> Source/WebKit/UIProcess/ios/ProcessStateMonitor.h:52
> +    WebCore::Timer m_suspendTimer;

You cannot use a WebCore::Timer in the UIProcess iirc because the app could be using both WK1 and WK2 in the UIProcess on iOS, and you could have a WebThread. 

You should be using a RunLoop::Timer<ProcessStateMonitor>.

> Source/WebKit/UIProcess/ios/ProcessStateMonitor.mm:37
> +static constexpr Seconds prepareForSuspensionDuration =  15_s;

nit: extra space before 15_s

> Source/WebKit/UIProcess/ios/ProcessStateMonitor.mm:51
> +            callOnMainRunLoop([weakThis] {

Are we sure RunningBoard never calls on on the main thread? If they might, we could use ensureOnMainRunLoop() and avoid a dispatch in some cases.

> Source/WebKit/UIProcess/ios/ProcessStateMonitor.mm:90
> +    Seconds timeout = remainingRunTime > prepareForSuspensionDuration ? remainingRunTime - prepareForSuspensionDuration : 0_s;

This function needs RELEASE_LOGGING

> Source/WebKit/UIProcess/ios/ProcessStateMonitor.mm:100
> +    m_becomeSuspendedHandler(true);

This function needs RELEASE_LOGGING
Comment 5 Sihui Liu 2022-05-15 22:39:40 PDT
Created attachment 459395 [details]
Patch
Comment 6 Sihui Liu 2022-05-16 09:28:46 PDT
Pull request: https://github.com/WebKit/WebKit/pull/637
Comment 7 Sihui Liu 2022-05-17 14:33:07 PDT
*** Bug 239432 has been marked as a duplicate of this bug. ***
Comment 8 EWS 2022-05-18 10:52:15 PDT
Committed r294405 (250699@main): <https://commits.webkit.org/250699@main>

Reviewed commits have been landed. Closing PR #637 and removing active labels.
Comment 9 Radar WebKit Bug Importer 2022-05-18 10:53:14 PDT
<rdar://problem/93514053>