Introduce ProcessNamespace?

[gterzian]

In both #23637 and #23909 I find myself installing PipelineNamspace in various threads that currently do not have one, mainly as a way to use various new types of Id that aren't PipelineId, like MessagePortId or IpcRouterId. Those need to follow a similar model since they can end-up crossing process boundaries(message-port), or need to be unique per process.

It can be quite hard to install a pipeline namespace for some threads, especially if those threads do not have a direct channel to the constellation. For example the threadpool used by layout, from within which calls are made to the font-cache(which I tried to refactor to use this prototype SharedIpcRouter).

For other threads, like dedicated workers and layout, it's merely an inconvenient blocking ipc call to the constellation.

So, perhaps we could have a ProcessNamespace be a lazy static, put a mutex around it(or make it an atomic), then each thread upon initialization could grab it, install a thread-local PipelineNamespace based on something like ProcessNamespace::new_pipeline_id(), which could be an easy way for a thread to install a PipelineNamespace without having to communicate with the constellation.

And the ProcessNamespace is something the constellation could seed, like is currently done with PipelineNamespace, when the process is created.

[gterzian]

I've tried, it felt like a good idea for a few hours, then I realized a process could just race ahead of another, and the only way to make sure each process is creating unique IDs is literally by using the constellation as a global lock and the single source of increasing namespace ids...

[gterzian]

However, this might still work if we were to make the PIPELINE_NAMESPACE itself something that is shared across threads. So that still requires the constellation to provide the PipelineNamespaceId, but that needs to be done only once per process, if we share the installed namespace with all threads in the process.