In bug 1503834 we have introduced a background bridging between workers on the content process and the socket process (I'm not entirely sure how that exactly works, tho). memory-only-PSM on the socket process running on the socket thread needs to send messages to the parent process where full-PSM runs to validate certs, best to a background (e.g. the existing socket) thread.

It sounds as if what you're looking for is mozilla::ipc::Endpoint[1], to set up communication between two arbitrary threads. If there's an existing protocol under PBackground that you want to use here, protocols can have alternate managers[2]. PBackground is, as I understand it, a collection of miscellaneous services used for rendering Web content where the client/child/content side can use them on an arbitrary thread (e.g., for DOM workers); the backend for all instances of it is a single dedicated non-main thread in the UI process. Bug 1503834 extended this so the socket process can take the place of the UI process, but I'd like to see if that can be refactored at some point. In any case, I don't think it makes sense for communication between the UI and socket processes. Or, looked at another way, PBackground is a hack to share a single OS-level transport (socketpair or named pipe) among several unrelated actor trees that were going to be dispatching to the same actor threads anyway. And this would be using entirely different threads. [1] https://searchfox.org/mozilla-central/rev/47edbd91c43db6229cf32d1fc4bae9b325b9e2d0/ipc/glue/ProtocolUtils.h#731-754 [2] Example: https://searchfox.org/mozilla-central/rev/47edbd91c43db6229cf32d1fc4bae9b325b9e2d0/gfx/layers/ipc/PTexture.ipdl#25

In other words, you suggest to not reuse the code in PBackground, but work with EndPoints directly, is that so? Whatever that does what I need and gets an r+ is fine :)