Bug 240359 – Monitor process state and send prepareToSuspend based on that

• Component: New Bugs
• Status: RESOLVED FIXED

[Sihui Liu]

...

[Sihui Liu]

Created attachment 459251 [details]
Patch

[Sihui Liu]

Created attachment 459306 [details]
Patch

[Geoffrey Garen]

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?

[Chris Dumez]

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

[Sihui Liu]

Created attachment 459395 [details]
Patch

[Sihui Liu]

Pull request: https://github.com/WebKit/WebKit/pull/637

[Sihui Liu]

*** Bug 239432 has been marked as a duplicate of this bug. ***

[EWS]

Committed r294405 (250699@main): <https://commits.webkit.org/250699@main>

Reviewed commits have been landed. Closing PR #637 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/93514053>