constellation: Break the EventLoop dependency on the initial Pipeline#40944
Conversation
|
🔨 Triggering try run (#19770036238) for Linux (WPT) |
|
|
|
|
||
| let event_loop = EventLoop::spawn(self, is_private)?; | ||
| if let Some(registered_domain_name) = registered_domain_name { | ||
| self.set_event_loop(&event_loop, registered_domain_name, webview_id, opener); |
There was a problem hiding this comment.
If we spawn an event loop but don't have a registered domain name, won't the new event loop be dropped immediately after we return? That seems like we should return an error instead of spawning in that case.
There was a problem hiding this comment.
Constellation::set_event_loop is only responsible for setting a Weak<EventLoop> on the BrowsingContextGroup so that it can be reused (if it's upgradeable in the future). What really keeps it alive here is the return value which should be valid until it is used when spawning the pipeline.
| pub(crate) namespace_ipc_sender: GenericSender<PipelineNamespaceRequest>, | ||
|
|
||
| /// A [`Vec`] of all [`EventLoop`]s that have been created for this [`Constellation`]. | ||
| /// This will be cleaned up periodically. This stores weak references so that [`EventLoop`]s |
There was a problem hiding this comment.
Cleanup happens during the spin of the Constellation event loop here: https://github.com/mrobinson/servo/blob/7e11aff754449b4a888898aeef561ebac0356b41/components/constellation/constellation.rs#L782
There was a problem hiding this comment.
I think that only cleans up the event_loop_join_handles, not event_loops.
There was a problem hiding this comment.
Oh. I see. You are right. I'll address this.
1caa3dc to
7e11aff
Compare
|
🔨 Triggering try run (#19781876818) for Linux (WPT) |
|
Test results for linux-wpt from try job (#19781876818): Flaky unexpected result (39)
Stable unexpected results that are known to be intermittent (25)
Stable unexpected results (6)
|
|
|
7e11aff to
e25b829
Compare
e25b829 to
78c87e5
Compare
|
I sent this to the MQ by accident. It will need a merge conflict fixed once #40951 lands. |
…ine`
Currently starting a script `EventLoop` depends on sending data about
the initial `Pipeline`. This change breaks this dependency. The goal
here is to:
1. Allow `ScriptThread`s to be shared between `WebView`s. This will
allow more flexiblity with the way that `ScriptThread`s are created,
which should allow us to perserve system resources by allowing them
to be shared between `WebView`s. With this change, we can do away
with the `InitialPipelineState` entirely, which was gather
information necessary for both a new `EventLoop` and a new
`Pipeline`. We no longer have to do many clones when reusing an
existing even loop.
1. Simplify the way that `EventLoop`s and `Pipeline`s are spawned. Now
`Pipeline`s are spawned in the same way no matter what.
Now the general order of operations when starting a pipeline is:
1. Get or create an event loop for the pipeline:
- If the event loop needs to be spawn, spawned it in a new thread or
process.
2. Send the spawn pipeline message to the event loop (kept alive via an
`Rc`.
Signed-off-by: Martin Robinson <[email protected]>
78c87e5 to
77c90b4
Compare
I inadvertently left this debugging code in before landing the change. Signed-off-by: Martin Robinson <[email protected]>
I inadvertently left this debugging code in before landing the change. Testing: This just removes an unexpected `println!` so no new tests are necessary. Signed-off-by: Martin Robinson <[email protected]>
Currently starting a script
EventLoopdepends on sending data aboutthe initial
Pipeline. This change breaks this dependency. The goalhere is to:
ScriptThreads to be shared betweenWebViews. This willallow more flexiblity with the way that
ScriptThreads are created,which should allow us to perserve system resources by allowing them
to be shared between
WebViews. With this change, we can do awaywith the
InitialPipelineStateentirely, which was gatherinformation necessary for both a new
EventLoopand a newPipeline. We no longer have to do many clones when reusing anexisting even loop.
EventLoops andPipelines are spawned. NowPipelines are spawned in the same way no matter what.Now the general order of operations when starting a pipeline is:
process.
Rc.Testing: This should not change behavior in a way that is observable, so should
be covered by existing tests.