dom/workers - mozsearch

firefox-main/dom/workers

	Name	Description	Size	Coverage
	ChromeWorker.cpp	static	2978	100 %
	ChromeWorker.h	unused	956	100 %
	ChromeWorkerScope.cpp		1765	82 %
	ChromeWorkerScope.h		522	-
	EventWithOptionsRunnable.cpp		4698	73 %
	EventWithOptionsRunnable.h		2050	0 %
	JSExecutionManager.cpp		7078	29 %
	JSExecutionManager.h		6809	33 %
	JSSettings.h		1940	93 %
	loader			83 %
	MessageEventRunnable.cpp		6223	74 %
	MessageEventRunnable.h		1693	100 %
	metrics.yaml		2120	-
	moz.build		2681	-
	nsIWorkerChannelInfo.idl		767	-
	nsIWorkerDebugger.idl		2435	-
	nsIWorkerDebuggerManager.idl		836	-
	Queue.h	mozilla_dom_workerinternals_Queue_h	4201	100 %
	RegisterBindings.cpp		1365	74 %
	remoteworkers			87 %
	RuntimeService.cpp		87197	79 %
	RuntimeService.h		6715	83 %
	ScriptLoader.cpp		70925	94 %
	ScriptLoader.h		13951	71 %
	sharedworkers			88 %
<1%	test			-
	Worker.cpp	static	8878	92 %
	Worker.h	mozilla_dom_Worker_h	4052	100 %
	WorkerChannelInfo.cpp		1769	75 %
	WorkerChannelInfo.h		1242	100 %
	WorkerCommon.h		2166	100 %
	WorkerCSPEventListener.cpp	static	2552	95 %
	WorkerCSPEventListener.h		1023	100 %
	WorkerDebugger.cpp		14674	85 %
	WorkerDebugger.h		1732	100 %
	WorkerDebuggerManager.cpp	anonymous namespace	10464	94 %
	WorkerDebuggerManager.h		3245	80 %
	WorkerDocumentListener.cpp		3233	95 %
	WorkerDocumentListener.h	mozilla_dom_WorkerDocumentListener_h_	1091	100 %
	WorkerError.cpp	isErrorEvent	15631	87 %
	WorkerError.h		2407	100 %
	WorkerEventTarget.cpp	aIsIPCMessage	8662	83 %
	WorkerEventTarget.h		1587	100 %
	WorkerIPCUtils.h		903	100 %
	WorkerLoadInfo.cpp		16546	95 %
	WorkerLoadInfo.h		7550	100 %
	WorkerLocation.cpp	static	1298	100 %
	WorkerLocation.h		2367	100 %
	WorkerNavigator.cpp	static	10563	99 %
	WorkerNavigator.h	unused	3699	95 %
	WorkerPrivate.cpp		241173	88 %
	WorkerPrivate.h		66361	97 %
	WorkerRef.cpp	static	7267	100 %
	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);	9059	91 %
	WorkerRunnable.cpp		25184	88 %
	WorkerRunnable.h		21415	84 %
	WorkerScope.cpp		52468	93 %
	WorkerScope.h		19721	77 %
	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 \| +-------------+-------------+-----------------+----------+	2064	-
	WorkerTestUtils.cpp		5432	79 %
	WorkerTestUtils.h	dom/webidl/WorkerTestUtils.webidl defines APIs to expose worker's internal status for glass-box testing. The APIs are only exposed to Workers with prefs dom.workers.testing.enabled. WorkerTestUtils is the implementation of dom/webidl/WorkerTestUtils.webidl	1879	-
	WorkerThread.cpp	aKey	10344	83 %
	WorkerThread.h		3636	100 %

Revision control

Other Tools