Name Description Size
ChromeWorker.cpp static 2583
ChromeWorker.h unused 1163
ChromeWorkerScope.cpp 1799
ChromeWorkerScope.h 672
JSExecutionManager.cpp 7257
JSExecutionManager.h nsRunnable 6939
JSSettings.h 2020
MessageEventRunnable.cpp 5605
MessageEventRunnable.h 1257
Principal.cpp 1138
Principal.h mozilla_dom_workers_principal_h__ 1160
Queue.h mozilla_dom_workerinternals_Queue_h 3918
RegisterBindings.cpp 1701
RuntimeService.cpp 78159
RuntimeService.h 5462
ScriptLoader.cpp 82451
ScriptLoader.h mozilla_dom_workers_scriptloader_h__ 2183
Worker.cpp static 6359
Worker.h mozilla_dom_Worker_h 2251
WorkerCSPEventListener.cpp static 2525
WorkerCSPEventListener.h 1047
WorkerCommon.h 1653
WorkerDebugger.cpp 15182
WorkerDebugger.h Sends back a PerformanceInfo struct from the counters in mWorkerPrivate. Counters are reset to zero after this call. 1821
WorkerDebuggerManager.cpp anonymous namespace 9640
WorkerDebuggerManager.h 3128
WorkerError.cpp isErrorEvent 17034
WorkerError.h 2330
WorkerEventTarget.cpp 3928
WorkerEventTarget.h 1565
WorkerLoadInfo.cpp 17280
WorkerLoadInfo.h 5823
WorkerLocation.cpp static 1571
WorkerLocation.h 2518
WorkerNavigator.cpp static 7373
WorkerNavigator.h unused 3132
WorkerPrivate.cpp 170497
WorkerPrivate.h 42792
WorkerRef.cpp static 6625
WorkerRef.h If you want to play with a DOM Worker, you must know that it can go away at any time if nothing prevents its shutting down. This documentation helps to understand how to play with DOM Workers correctly. There are several reasons why a DOM Worker could go away. Here is the complete list: a. GC/CC - If the DOM Worker thread is idle and the Worker object is garbage collected, it goes away. b. The worker script can call self.close() c. The Worker object calls worker.terminate() d. Firefox is shutting down. When a DOM Worker goes away, it does several steps. See more in WorkerStatus.h. The DOM Worker thread will basically stop scheduling WorkerRunnables, and eventually WorkerControlRunnables. But if there is something preventing the shutting down, it will always possible to dispatch WorkerControlRunnables. Of course, at some point, the worker _must_ be released, otherwise firefox will leak it and the browser shutdown will hang. WeakWorkerRef is a refcounted, NON thread-safe object. From this object, you can obtain a WorkerPrivate, calling WeakWorkerRef::GetPrivate(). It returns nullptr if the worker is shutting down or if it is already gone away. If you want to know when a DOM Worker starts the shutting down procedure, pass a callback to the mozilla::dom::WeakWorkerRef::Create() method. Your function will be called. Note that _after_ the callback, WeakWorkerRef::GetPrivate() will return nullptr. How to keep a DOM Worker alive? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you need to keep the worker alive, you must use StrongWorkerRef. You can have this refcounted, NON thread-safe object, calling mozilla::dom::StrongWorkerRef::Create(WorkerPrivate* aWorkerPrivate); If you have a StrongWorkerRef: a. the DOM Worker is kept alive. b. you can have access to the WorkerPrivate, calling: Private(). c. WorkerControlRunnable can be dispatched. Note that the DOM Worker shutdown can start at any time, but having a StrongWorkerRef prevents the full shutdown. Also with StrongWorkerRef, you can pass a callback when calling mozilla::dom::StrongWorkerRef::Create(). When the DOM Worker shutdown starts, WorkerRunnable cannot be dispatched anymore. At this point, you should dispatch WorkerControlRunnable just to release resources. How to have a thread-safe DOM Worker reference? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sometimes you need to play with threads and you need a thread-safe worker reference. ThreadSafeWorkerRef is what you want. Just because this object can be sent to different threads, we don't allow the setting of a callback. It would be confusing. ThreadSafeWorkerRef can be destroyed in any thread. Internally it keeps a reference to its StrongWorkerRef creator and this ref will be dropped on the correct thread when the ThreadSafeWorkerRef is deleted. IPC WorkerRef ~~~~~~~~~~~~~ IPDL protocols require a correct shutdown sequence. Because of this, they need a special configuration: 1. they need to be informed when the Worker starts the shutting down 2. they don't want to prevent the shutdown 3. but at the same time, they need to block the shutdown until the WorkerRef is not longer alive. Point 1 is a standard feature of WorkerRef; point 2 is similar to WeakWorkerRef; point 3 is similar to StrongWorkerRef. You can create a special IPC WorkerRef using this static method: mozilla::dom::IPCWorkerRef::Create(WorkerPrivate* aWorkerPrivate, const char* * aName); 8098
WorkerRunnable.cpp 23341
WorkerRunnable.h nsRunnable 19166
WorkerScope.cpp 36721
WorkerScope.h 14263
WorkerStatus.h Use this chart to help figure out behavior during each of the closing statuses. Details below. +========================================================+ | Closing Statuses | +=============+=============+=================+==========+ | status | clear queue | abort execution | notified | +=============+=============+=================+==========+ | Closing | yes | no | no | +-------------+-------------+-----------------+----------+ | Canceling | yes | yes | yes | +-------------+-------------+-----------------+----------+ | Killing | yes | yes | yes | +-------------+-------------+-----------------+----------+ 2211
WorkerThread.cpp aKey 10669
WorkerThread.h 3406 2338
nsIWorkerDebugger.idl 2093
nsIWorkerDebuggerManager.idl 627
remoteworkers 23
sharedworkers 12
test 277