Bugzilla

(In reply to Andrew McCreight [:mccr8] from comment #3)
> This is actually forget skippable, which runs outside of the CC. Maybe we need to check if shutdown has started before we do that? I know we have checks like that in a few places but maybe not for forget skippable?

My assumption is that at least in the example from comment 0 the runnable is already executed when `NotifiedImpendingShutdown` is called on the `IPC I/O` thread, otherwise we should probably see the `RecvShutdownConfirmedHP` annpotation in `IPC shutdown state` (as that is scheduled with high priority). I thus doubt that checking before we start to run this is enough and that we should have something similar like we have for JS (see bug  1777198) to interrupt (note to myself that we still need to flip that pref for release). But there might be also other ways to shorten this runnables' runtime, like checking for how long we already ran? After all it sounds bad to potentially block the main thread such long for an idle task not only for the shutdown case.

(In reply to Steve Fink [:sfink] [:s:] from comment #4)
> `ProcessChild` could expose a public accessor to `sExpectingShutdown`, I guess? I don't know if it's ok for nsJSEnvironment.cpp or CCGCScheduler.h to access that.

We already have `mozilla::ipc::ProcessChild::ExpectingShutdown()`. The underlying `sExpectingShutdown` is atomic (and it is ever set only in child processes). So technically it would work to access it from everywhere inside our process, not sure if it is sound. We [currently use it](https://searchfox.org/mozilla-central/search?q=mozilla%3A%3Aipc%3A%3AProcessChild%3A%3AExpectingShutdown%28%29&path=&case=true&regexp=false) in the process hang monitor and to cancel synchronous local storage requests.

(In reply to Andrew McCreight [:mccr8] from comment #3)
> This is actually forget skippable, which runs outside of the CC. Maybe we need to check if shutdown has started before we do that? I know we have checks like that in a few places but maybe not for forget skippable?

My assumption is that at least in the example from comment 0 the runnable is already executed when `NotifiedImpendingShutdown` is called on the `IPC I/O` thread, otherwise we should probably see the `RecvShutdownConfirmedHP` annpotation in `IPC shutdown state` (as that is scheduled with high priority). I thus doubt that checking before we start to run this is enough and that we should have something similar like we have for JS (see bug  1777198) to interrupt while running (note to myself that we still need to flip that pref for release). But there might be also other ways to shorten this runnables' runtime, like checking for how long we already ran? After all it sounds bad to potentially block the main thread such long for an idle task not only for the shutdown case.

(In reply to Steve Fink [:sfink] [:s:] from comment #4)
> `ProcessChild` could expose a public accessor to `sExpectingShutdown`, I guess? I don't know if it's ok for nsJSEnvironment.cpp or CCGCScheduler.h to access that.

We already have `mozilla::ipc::ProcessChild::ExpectingShutdown()`. The underlying `sExpectingShutdown` is atomic (and it is ever set only in child processes). So technically it would work to access it from everywhere inside our process, not sure if it is sound. We [currently use it](https://searchfox.org/mozilla-central/search?q=mozilla%3A%3Aipc%3A%3AProcessChild%3A%3AExpectingShutdown%28%29&path=&case=true&regexp=false) in the process hang monitor and to cancel synchronous local storage requests.