You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: dom/docs/workersAndStorage/WorkerLifeCycleAndWorkerRefs.md
+12-12
Original file line number
Diff line number
Diff line change
@@ -19,9 +19,9 @@ The worker’s life cycle is maintained by a status machine in the WorkerPrivate
19
19
Following we briefly describe what is done for each status.
20
20
21
21
22
-
### Pending:
22
+
### Pending:
23
23
24
-
This is the initial status of a Worker.
24
+
This is the initial status of a Worker.
25
25
26
26
Worker’s initialization is done in this status in the parent(main or the parent worker) and worker thread.
27
27
@@ -34,9 +34,9 @@ Worker’s initialization starts from its parent thread, which includes
34
34
5. Connect debugger
35
35
6. Dispatch CompileScriptRunnable to the worker thread
36
36
37
-
Before the Worker thread starts running runnables, a Worker could have already been exposed to its parent window/worker. So the parent window/worker can send messages to the worker through the postMessage() method. If the Worker is not in the “Running” status yet, these runnables would be kept in WorkerPrivate::mPreStartRunnables.
37
+
Before the Worker thread starts running runnables, a Worker could have already been exposed to its parent window/worker. So the parent window/worker can send messages to the worker through the postMessage() method. If the Worker is not in the “Running” status yet, these runnables would be kept in WorkerPrivate::mPreStartRunnables.
38
38
39
-
When WorkerThreadPrimaryRunnable starts executing on the worker thread, it continues the initialization on the worker thread, which includes
39
+
When WorkerThreadPrimaryRunnable starts executing on the worker thread, it continues the initialization on the worker thread, which includes
40
40
41
41
1. Build the connection between WorkerPrivate and the worker thread. Then moving the WorkerPrivate::mPreStartRunnables to the worker thread’s event queue.
42
42
2. Initialize the PerformanceStorage for the Worker.
@@ -60,12 +60,12 @@ Once the Worker gets into “Running”,
60
60
2. Create sync-eventLoop to make the worker thread to wait for another thread's execution.
61
61
3. Dispatching events to WorkerGlobalScope to trigger event callbacks defined in the script.
62
62
63
-
We will talk about WorkerRef, Sync-EventLoop in detail later.
63
+
We will talk about WorkerRef, Sync-EventLoop in detail later.
64
64
65
65
66
66
### Closing:
67
67
68
-
This is a special status for DedicatedWorker and SharedWorker when DedicateWorkerGlobalScope.close()/SharedWorkerGlobalScope.close() is called.
68
+
This is a special status for DedicatedWorker and SharedWorker when DedicateWorkerGlobalScope.close()/SharedWorkerGlobalScope.close() is called.
69
69
70
70
When Worker enters into the “Closing” status,
71
71
@@ -92,7 +92,7 @@ So the WorkerRef holders and children Workers will start the shutdown jobs
92
92
93
93
Once all sync-eventLoops are closed,
94
94
95
-
1.Disconnect the EventTarget/WebTaskScheduler of the WorkerGlobalScope
95
+
1. Disconnect the EventTarget/WebTaskScheduler of the WorkerGlobalScope
96
96
97
97
98
98
### Killing:
@@ -133,7 +133,7 @@ The WorkerPrivate is supposed to be released after its self-reference is nullifi
133
133
134
134
Normally, there are four situations making a Worker get into shutdown.
135
135
136
-
1. Worker is GC/CCed.
136
+
1. Worker is GC/CCed.
137
137
138
138
1. Navigating to another page.
139
139
2. Worker is idle for a while. (Notice that idle is not a status of Worker, it is a condition in “Running” status)
@@ -176,7 +176,7 @@ According to the following requirements, four types of WorkerRefs are introduced
176
176
177
177
### WeakWorkerRef
178
178
179
-
WeakWorkerRef, as its name, is a “Weak” reference since WeakWorkerRef releases the internal reference to the Worker immediately after WeakWorkerRef’s registered callback execution completes. Therefore, WeakWorkerRef does not block the Worker’s shutdown. In addition, holding a WeakWorkerRef would not block GC/CC the Worker. This means a Worker will be considered to be cycle-collected even if there are WeakWorkerRefs to the Worker.
179
+
WeakWorkerRef, as its name, is a “Weak” reference since WeakWorkerRef releases the internal reference to the Worker immediately after WeakWorkerRef’s registered callback execution completes. Therefore, WeakWorkerRef does not block the Worker’s shutdown. In addition, holding a WeakWorkerRef would not block GC/CC the Worker. This means a Worker will be considered to be cycle-collected even if there are WeakWorkerRefs to the Worker.
180
180
181
181
WeakWorkerRef is ref-counted, but not thread-safe.
182
182
@@ -189,7 +189,7 @@ Unlike WeakWorkerRef, StrongWorkerRef does not release its internal reference to
189
189
190
190
When using the StrongWorkerRef, resource cleanup might involve multiple threads and asynchronous behavior. StrongWorkerRef release timing becomes crucial not to cause memory problems, such as UAF or leaking. StrongWorkerRef must be released. Otherwise, a shutdown hang would not be a surprise.
191
191
192
-
StrongWorkerRef also blocks the GC/CC a Worker. Once there is a StrongWorkerRef to the Worker, GC/CC will not collect the Worker.
192
+
StrongWorkerRef also blocks the GC/CC a Worker. Once there is a StrongWorkerRef to the Worker, GC/CC will not collect the Worker.
193
193
194
194
StrongWorkerRef is ref-counted, but not thread-safe.
195
195
@@ -207,7 +207,7 @@ ThreadSafeWorkerRef is ref-counted and thread-safe.
207
207
208
208
IPCWorkerRef is a special WorkerRef for IPC actors which binds its life-cycle with Worker’s shutdown notification. (In our current codebase, Cache API and Client API uses IPCWorkerRef)
209
209
210
-
Because some IPC shutdown needs to be in a special sequence during the Worker's shutdown. However, to make these IPC shutdown needs to ensure the Worker is kept alive, so IPCWorkerRef blocks the Worker's shutdown. But IPC shutdown no need to block GC/CC a Worker.
210
+
Because some IPC shutdown needs to be in a special sequence during the Worker's shutdown. However, to make these IPC shutdown needs to ensure the Worker is kept alive, so IPCWorkerRef blocks the Worker's shutdown. But IPC shutdown no need to block GC/CC a Worker.
211
211
212
212
IPCWorkerRef is ref-counted, but not thread-safe.
213
213
@@ -218,7 +218,7 @@ Following is a table for the comparison between WorkerRefs
0 commit comments