| Summary: | [iOS] Assert that WebProcessProxy::didBecomeUnresponsive is called if the service worker process takes no process assertion | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | youenn fablet <youennf> | ||||||
| Component: | Service Workers | Assignee: | youenn fablet <youennf> | ||||||
| Status: | RESOLVED CONFIGURATION CHANGED | ||||||||
| Severity: | Normal | CC: | beidson, cdumez | ||||||
| Priority: | P2 | ||||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
|
Description
youenn fablet
2020-02-05 05:47:52 PST
Created attachment 389799 [details]
Patch
Created attachment 389801 [details]
Patch
Comment on attachment 389801 [details]
Patch
Looks like a racy assertion to me. A process could be unresponsive before we drop the assertions and then the responsiveness timer would fire. If you want to protect against this, maybe we should just stop the responsiveness timer when we get the response to PrepareToSuspend IPC.
(In reply to Chris Dumez from comment #3) > Comment on attachment 389801 [details] > Patch > > Looks like a racy assertion to me. A process could be unresponsive before we > drop the assertions and then the responsiveness timer would fire. If you > want to protect against this, maybe we should just stop the responsiveness > timer when we get the response to PrepareToSuspend IPC. My guess was that it might help explaining flakiness issues. I was thinking we could enable/disable the responsiveness timer when we take assertions. I am not familiar with this responsiveness timer logic, maybe that would conflict with logic enabling/disabling the timer by pages. Disabling the timer when we know the process is about to suspend seems good too. (In reply to youenn fablet from comment #4) > (In reply to Chris Dumez from comment #3) > > Comment on attachment 389801 [details] > > Patch > > > > Looks like a racy assertion to me. A process could be unresponsive before we > > drop the assertions and then the responsiveness timer would fire. If you > > want to protect against this, maybe we should just stop the responsiveness > > timer when we get the response to PrepareToSuspend IPC. > > My guess was that it might help explaining flakiness issues. > I was thinking we could enable/disable the responsiveness timer when we take > assertions. I am not familiar with this responsiveness timer logic, maybe > that would conflict with logic enabling/disabling the timer by pages. > Disabling the timer when we know the process is about to suspend seems good > too. We see flakiness on debug bots and the responsiveness timer is disabled in debug. Closing since timer is no longer enabled on debug bots |