Introduce a namespace installer

[gterzian]

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix #23932 (GitHub issue number if applicable)

• There are tests for these changes OR
• These changes do not require tests because ___

---

This change is 

[highfive]

Heads up! This PR modifies the following files:

• @asajeffrey: components/constellation/constellation.rs, components/script/script_thread.rs
• @cbrewster: components/constellation/constellation.rs
• @KiChjang: components/script/script_thread.rs

[highfive]

Warning

• These commits modify script code, but no tests are modified. Please consider adding a test!

[gterzian]

I think this is better than the current manual counting of pipeline-namespace that goes on in servo/lib and constellation, it becomes downright useful in the light of for example #23637

Where in order to install a pipeline-namespace in a worker thread, you need to make a blocking ipc call to the constellation, see https://github.com/servo/servo/pull/23637/files#diff-c3210c2a1bf5e1de39588154cd766100R390

The above could be replaced by a simple call in the worker to PipelineNamespace::install(ProcessNamespace::next_pipeline_namespace_id());

It would also be useful to install a pipeline-namespace in threads that do not have a direct channel to the constellation, for example the style threadpool(the reason why it might need one is anything requiring creating unique Ids, for example using the shared-ipc router prototyped at #23909, which currently can't work with parallel layout, as the communication with the font-cache occurs from a rayon thread from which it isn't easy to ask the constellation for a pipeline-namespace id).

[gterzian]

This isn't going to work in multiprocess, since there is nothing to prevent one process to race ahead of the other if the namespace is just a u32....

I think the only way is tot actually use the constellation as a global lock...

[gterzian]

Actually, the last commit might be something the could work. It means we'd still use the constellation to provide the PipelineNamspaceId to install a pipeline-namespace, and it would then be shared with all threads in the process, so each could use it to create Ids without having to install it's own.

The downside is that the namespace becomes a kind of contended resource for all threads in a process, yet this might not matter in practice. If it were to become a problem, it could be solved by adding some intermediary per-thread namespace, that would be installed using the per-process namespace...

This could definitely make it much easier to start using the name-space from a bunch of other threads, without having to orchestrate installing it via the constellation.

[gterzian]

@bors-servo try=wpt

[bors-servo]

⌛ Trying commit be5d0de with merge d8aef35...

[bors-servo]

☀️ Test successful - linux-rel-css, linux-rel-wpt, status-taskcluster
State: approved= try=True

[gterzian]

@jdm Ok here is the latest variation on the same theme. I think this can be a way to address https://github.com/servo/servo/pull/23637/files#r312133197 generally across all threads.

So, still using the constellation as a single source of unique per UA PipelineNamespaceId, and now adding a per-process PipelineNameSpaceInstaller that is shared with all threads in the process, and that can be used to setup thread-local pipeline-namespaces.

It's better than the previous version since it keeps the actual namespace as a thread-local, and it improves on the current situation since it makes it easy for any thread to install a namespace.

It improves on the code at https://github.com/servo/servo/pull/23637/files by removing the need for threads to have their own plumbing to ask the constellation for a namespace. For example, with this any thread in a rayon pool could get it's own namespace without needing to setup a channel with the constellation directly or otherwise being aware of how a namespace is installed.

Still building to test if it actually works, I think it should be ok.

[bors-servo]

⌛ Trying commit 0630426 with merge 9910907...

[bors-servo]

☀️ Test successful - linux-rel-css, linux-rel-wpt, status-taskcluster
State: approved= try=True

[gterzian]

@jdm this is is ready for review, I haven't squashed those commits since I'm not sure the "batching of Ids" is a good idea, so that commit could still be removed.

This is somewhat relevant for the messageport PR, since it could rebase off of this one and simplify the worker code that installs pipeline namespaces.

[jdm]

These changes look fine, but I don't think we need the batch generation.

[jdm]

I imagine that any IPC for pipeline namespace generation will be completely dwarfed by the time it takes for the network request to complete. I don't think this is worth including without data backing it up.

[gterzian]

Ok, rebased as well...

[jdm]

@bors-servo r+

[bors-servo]

📌 Commit 34008a3 has been approved by jdm

[bors-servo]

⌛ Testing commit 34008a3 with merge ba1fa08...

[bors-servo]

☀️ Test successful - linux-rel-css, linux-rel-wpt, status-taskcluster
Approved by: jdm
Pushing ba1fa08 to master...