Improve the stability of keepalive decisions based on the ThreadsafeContentParentHandle
Categories
(Core :: DOM: Content Processes, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox116 | --- | fixed |
People
(Reporter: jstutte, Assigned: jstutte)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
There is a time window between the first check in ContentParent::NotifyTabWillDestroy
and the flagging of mThreadsafeHandle->mShutdownStarted
in ContentParent::MaybeAsyncSendShutDownMessage
during which a worker might have tried to register for our process. The entire sequence is happening in the same MT runnable processing, so the time window is small but exists.
This race would leave us with a process that is never told to shutdown and then killed directly by the ContentParent::ForceKillTimerCallback
.
Assignee | ||
Comment 1•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
As we closed the other bug, I lift this dependency up to the parent.
Actually there are still some cases of "GetRunnableForMTTask seems to be stuck on mMainThreadCV.Wait();" after bug 1837467 landed, this bug might be one way to cause them.
Comment 4•2 years ago
|
||
Backed out for bc failure on RecursiveMutex.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/ee06d59277b42e5c3ddb28abf800a6c4a8aca6b5
Log link: https://treeherder.mozilla.org/logviewer?job_id=420123719&repo=autoland&lineNumber=2757
Comment 6•2 years ago
•
|
||
Backed out changeset 81e6aadf9911 (bug 1838779) for causing build bustage at ContentParent.cpp
Backout: https://hg.mozilla.org/integration/autoland/rev/c3a77b177cd08f50313ea3ff4c21c7ff0342590b
Failure log: https://treeherder.mozilla.org/logviewer?job_id=420156947&repo=autoland&lineNumber=11228
Comment 8•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Description
•