Struct script::dom::worklet::WorkletThreadPool

pub struct WorkletThreadPool {
    primary_sender: Sender<WorkletData>,
    hot_backup_sender: Sender<WorkletData>,
    cold_backup_sender: Sender<WorkletData>,
    control_sender_0: Sender<WorkletControl>,
    control_sender_1: Sender<WorkletControl>,
    control_sender_2: Sender<WorkletControl>,
}

Worklets execute in a dedicated thread pool.

The goal is to ensure that there is a primary worklet thread, which is able to responsively execute worklet code. In particular, worklet execution should not be delayed by GC, or by script loading.

To achieve this, we implement a three-thread pool, with the threads cycling between three thread roles:

• The primary worklet thread is the one available to execute worklet code.

• The hot backup thread may peform GC, but otherwise is expected to take over the primary role.

• The cold backup thread may peform script loading and other long-running tasks.

In the implementation, we use two kinds of messages:

• Data messages are expected to be processed quickly, and include the worklet tasks to be performed by the primary thread, as well as requests to change role or quit execution.

• Control messages are expected to be processed more slowly, and include script loading.

Data messages are targeted at a role, for example, task execution is expected to be performed by whichever thread is currently primary. Control messages are targeted at a thread, for example adding a module is performed in every thread, even if they change roles in the middle of module loading.

The thread pool lives in the script thread, and is initialized when a worklet adds a module. It is dropped when the script thread is dropped, and asks each of the worklet threads to quit.

Layout can end up blocking on the primary worklet thread (e.g. when invoking a paint callback), so it is important to avoid deadlock by making sure the primary worklet thread doesn’t end up blocking waiting on layout. In particular, since the constellation can block waiting on layout, this means the primary worklet thread can’t block waiting on the constellation. In general, the primary worklet thread shouldn’t perform any blocking operations. If a worklet thread needs to do anything blocking, it should send a control message, to make sure that the blocking operation is performed by a backup thread, not by the primary thread.

Fields

primary_sender: Sender<WorkletData>

hot_backup_sender: Sender<WorkletData>

cold_backup_sender: Sender<WorkletData>

control_sender_0: Sender<WorkletControl>

control_sender_1: Sender<WorkletControl>

control_sender_2: Sender<WorkletControl>

Implementations

impl WorkletThreadPool

pub fn spawn(global_init: WorkletGlobalScopeInit) -> WorkletThreadPool

Create a new thread pool and spawn the threads. When the thread pool is dropped, the threads will be asked to quit.

fn fetch_and_invoke_a_worklet_script( &self, pipeline_id: PipelineId, worklet_id: WorkletId, global_type: WorkletGlobalScopeType, origin: ImmutableOrigin, base_url: ServoUrl, script_url: ServoUrl, credentials: RequestCredentials, pending_tasks_struct: PendingTasksStruct, promise: &Rc<Promise>, )

Loads a worklet module into every worklet thread. If all of the threads load successfully, the promise is resolved. If any of the threads fails to load, the promise is rejected. https://drafts.css-houdini.org/worklets/#fetch-and-invoke-a-worklet-script

pub(crate) fn exit_worklet(&self, worklet_id: WorkletId)

pub fn test_worklet_lookup(&self, id: WorkletId, key: String) -> Option<String>

For testing.

fn wake_threads(&self)

Trait Implementations

impl Clone for WorkletThreadPool

fn clone(&self) -> WorkletThreadPool

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Drop for WorkletThreadPool

fn drop(&mut self)

Executes the destructor for this type.

impl Traceable for WorkletThreadPool

unsafe fn trace(&self, tracer: *mut JSTracer)

Trace self.