1876306 - Prevent main thread QoS priority changes during shutdown

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Kris Wright :KrisWright]

This bug was created in response to issues with QoS priority found in bug 1864641. It's possible that a mainthread finds itself unable to wake up during shutdown, due to being put into the background during the shutdown process. The entire content process then gets stuck, because the main thread is idle.

I can't prove that this is the issue we're seeing in the above bug, but plugging this hole in the code will ensure that we don't run into this issue in the wild (if we are). A simple solution is to just signal before we send the first shutdown signal that we want to warm up the main thread, and ignore all QoS change calls after that. We're completely fine to ignore QoS change calls if the most recent change set the main thread to its highest priority.

Comment 1

[Kris Wright :KrisWright]

Attachment: Bug 1876306 - Signal to content processes shutting down to raise the QoS priority of their main thread, then ignore all other QoS changes. r?nika

This patch introduces QOS_PRIORITY_SHUTDOWN, which exists exclusively to signal to QoS managing code that we want to raise the priority and accept no other changes. I decided to make this modification directly in ContentParent since all QoS changes come through here, and then we can use it while sending a shutdown signal. That way when we actually reach SendShutdown(), we've already warmed up the main thread.

This patch also introduces an assertion in case we somehow don't get a QoS override to catch any potential edge cases where this might be happening.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b3c8cbb6886c
Signal to content processes shutting down to raise the QoS priority of their main thread, then ignore all other QoS changes. r=nika

Comment 4

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/b3c8cbb6886c