Open Bug 1683595 Opened 4 years ago Updated 1 year ago

Refactor remote worker process selection, spawning, and "does this process need to stay alive" to the main thread and ContentParent and exposed to ChildProcInfoDictionary

Categories

(Core :: DOM: Workers, enhancement, P3)

Product:
Core
Component:
DOM: Workers
Type:
enhancement

Tracking

()

Status:
ASSIGNED

People

(Reporter: asuth, Assigned: asuth)

References

(Blocks 1 open bug)

Details

RemoteWorkerManager currently selects processes to spawn a worker into on the PBackground ("IPDL Background") thread and uses some very hacky mutex-protected book-keeping to mark those processes as in use by remote workers. When RemoteWorkerManager finds it needs a process that it doesn't think exists, it sends a request to the main thread to spawn a process and fails to use the existing keepalive mechanism to ensure the process is kept alive for its initial startup. While this works surprisingly well (and better after bug 1641715 fixed a permission transmission edge case) despite the number of edge cases that aren't really handled, this needs to be fixed for sanity, reliability, and so that about:processes (bug 1663737) and our tests (using the same mechanism) can know what worker is in what process.

The general idea is:

  • Introduce a RemoteWorkerKeepAlive that is issued by ContentParent that self-describes the worker for about:processes/debugging and serves as the first-class keep-alive for the process.
    • This also will let the owner/holder know if the process fails to spawn, allowing RemoteWorkerManager to avoid experiencing a hang.
  • ServiceWorkerManager already decides to spawn remote workers from the main thread.
  • SharedWorker infra already does book-keeping on the main thread, making it feasible to likewise do work on the main thread.

I have a WIP (Work In Progress) from bug 1662925 that I'm going to finish up to implement this.

You need to log in before you can comment on or make changes to this bug.