mirror of
https://github.com/servo/servo.git
synced 2025-09-23 05:10:09 +01:00
net: Remove CoreResourceThread
from FetchThread
state (#38422)
In single process mode, there is a race condition on the initialization of the global fetch thread: once initialized the global fetch thread will always use a given core resource thread, and this will be determined by the component who first initializes it. For example, if the canvas paint thread first does an async fetch, then this will set the public core resource as used for all future fetches, including those coming from a pipeline in private mode. In multi-process mode, there is a race condition per window event-loop: the first pipeline to use the fetch will set the core resource thread for all others. To ensure the fetch thread uses the correct core resource thread(private vs public), we need to pass the core resource thread to each fetch thread operation for which is it needed. Testing: It should not break existing fetch WPT tests. The race condition is not something that can be tested reliably, but it seems to be based on solid logic. Fixes: follow-up from https://github.com/servo/servo/pull/38421/files#r2248950924 --------- Signed-off-by: gterzian <2792687+gterzian@users.noreply.github.com>
This commit is contained in:
parent
5ff084a688
commit
70be996a29
11 changed files with 87 additions and 50 deletions
|
@ -733,7 +733,7 @@ where
|
|||
// Start a fetch thread.
|
||||
// In single-process mode this will be the global fetch thread;
|
||||
// in multi-process mode this will be used only by the canvas paint thread.
|
||||
let join_handle = start_fetch_thread(&self.public_resource_threads.core_thread);
|
||||
let join_handle = start_fetch_thread();
|
||||
|
||||
while !self.shutting_down || !self.pipelines.is_empty() {
|
||||
// Randomly close a pipeline if --random-pipeline-closure-probability is set
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue