Currently, PBackground is a big bag of protocols used for various purposes on non-main threads in content processes, and a mechanism to share the IPC transport when there are several of those protocols between the same pair of threads, and a dedicated shared non-main thread in the non-content process for handling the “parent” side.

It would be good to factor out the per-thread connection pooling and split PBackground into smaller sets of protocols for more specific purposes: communicating with the parent process vs. socket process, and DOM worker threads vs. other content threads if any. There are also problems with sharing a single “background” thread in the non-content process, like bug 1407415; that might be a use case for a separate background instance, or possibly it just could move to using its own Endpoint.

(This bug is filed in IPC, even though PBackground officially belongs to DOM, because the generalized connection pooling I'm proposing would probably live under ipc/.)