RESOLVED FIXED207144
Stop relying on ResponsivenessTimer to keep the WebProcess from suspending during initialization
https://bugs.webkit.org/show_bug.cgi?id=207144
Summary Stop relying on ResponsivenessTimer to keep the WebProcess from suspending du...
Chris Dumez
Reported 2020-02-03 13:55:45 PST
Stop relying on ResponsivenessTimer to keep the WebProcess from suspending during initialization. Instead, make the WebProcess::InitializeWebProcess IPC async with a reply and take a process assertion on behalf of the WebContent process until we get a response back. This avoids sending an extra PING IPC to the WebProcess for no reason (since we're already sending the WebProcess::InitializeWebProcess IPC) and this is also more reliable since the ResponsivenessTimer can actually time out and cause the process to get suspended during initialization still.
Attachments
Patch (5.69 KB, patch)
2020-02-03 13:57 PST, Chris Dumez
no flags
Chris Dumez
Comment 1 2020-02-03 13:57:51 PST
WebKit Commit Bot
Comment 2 2020-02-03 21:47:02 PST
Comment on attachment 389563 [details] Patch Clearing flags on attachment: 389563 Committed r255662: <https://trac.webkit.org/changeset/255662>
WebKit Commit Bot
Comment 3 2020-02-03 21:47:03 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 4 2020-02-03 21:48:15 PST
Chris Dumez
Comment 5 2020-02-04 08:30:04 PST
Follow-up fix for assertions on bots: <https://trac.webkit.org/changeset/255679>
Chris Dumez
Comment 6 2020-02-04 15:11:05 PST
(In reply to Chris Dumez from comment #5) > Follow-up fix for assertions on bots: > <https://trac.webkit.org/changeset/255679> Improved follow up fix: https://trac.webkit.org/changeset/255705/webkit
Chris Dumez
Comment 7 2020-02-05 08:28:13 PST
Chris Dumez
Comment 8 2020-02-11 16:31:28 PST
Note You need to log in before you can comment on or make changes to this bug.