The implementation mechanism of WEB worker in WebKit

Web worker is a JavaScript that executes in the background, independent of other scripts. Does not affect the performance of the page. This is a standard for HTML5; The browser initiates a new thread for Wokrer, which realizes the function of asynchronous operation;

Here is a simple example of woker. In the HTML page. Use Worker.js as the source file. A worker object named "worker" is created. A message is sent to the worker thread through the worker.postmessage () interface, and the worker thread adds the two data that the JSON format passes. The message is then sent back to the main thread of the page JS execution via the PostMessage () interface. The main thread then processes the messages sent from the Woker thread in the OnMessage () function;

Main.html

Worker.js
OnMessage = function (event)  {     var data = Event.data;   var First=data.first;   var Second=data.second;   Handletask (First,second);  };  function  Handletask (A, B)  {    var out = a + b;    PostMessage ("Worker done! out = "+ out";  }

The process of WebKit loading and running JS is simply divided into the following steps:
1. Run to "var worker = new Worker (' Worker.js ')". Constructs the Webcore::jsworker object (jsbbindings layer) in the kernel and the corresponding Webcore::worker object (WebCore module);
2. In the process of constructing the Jsworker object, the asynchronous loading process is initiated according to the initialized URL address "worker.js";
3. Run Worker.postmessage (). Sends JSON-formatted message data to the worker thread; The worker thread has not yet been created, so the message data is placed in a temporary message queue;
4. Worker.js The worker thread is created and started when the asynchronous load is complete. and copy the message data from the temporary message queue to the message queue of woker corresponding workerrunloop;
5. After the worker thread is created. Start processing messages stored in the message queue of Workerrunloop;
6. The Woker thread sends the message to the main thread.
7. The main thread receives a message sent by the worker thread, running OnMessage ();
After a round of messages, we assume that the message is sent asynchronously by a button in the sample. Then the operation of Step 3 will be different, this time because the worker thread has been created. So the message is added directly to the Workerrunloop message queue;

To figure out the entire implementation mechanism, let's take a look at the WebKit internal worker related classes. In the worker corresponding to the main page JS in the ' Worker ' object (in the main thread), while Dedicatedworkerthread represents the worker thread; Workermessagingproxy associates the worker object with the worker thread, Thus realizing the message relay between the main thread and the worker thread; Dedicatedworkerthread the script in the Worker.js file is run in the worker thread through Workerscriptcontroller, and the browser creates a separate virtual machine environment (VM) for the worker thread;

Take a look at the specific process:
1. Asynchronous loading steps for Worker.js, for example, are initiated when the Webcore::jsworker and Webcore::worker objects are created. And it is the asynchronous loading process that does not clog up the JS run, which is why the first call to Worker.postmessage (). There are cases where the worker thread has not been created;


2. The worker thread is created, for example, as seen.
Can see. When the worker.js is loaded. The WebKit creates Dedicatedworkerthread objects through the brokered object Workermessagingproxy and initiates workerthread; Workermessagingproxy Keep pointers to dedicatedworkerthread objects;

3. The process by which the main thread sends messages to the worker thread, such as the following. When JS runs to "Worker.postmessage ()", finally through the JS main thread virtual machine mapping to Jsworker::p ostmessage () function, The message queue is joined to the worker through the brokered object Workermessagingproxy. Suppose that the worker thread was not created when the message was sent. We see a M_queueearlytasks object that temporarily saves the current message and then transfers it to the formal message queue after the worker thread is created; The message is added directly to the official message queue of the Workerrunloop management;

4. The process of processing messages in a worker thread is as follows. This is the process of running "onmessage ()" In Worker.js, and we are able to see the Dedicatedworkthread object in its own thread environment Runloop take out the data in the message queue to run. The run is done by Eventtarget::d ispatchevent () Distributing and fire a "message" type of event;

.

5. Is the process of sending messages in a worker thread, as well as through Workermessagingproxy. The document is then triggered::p the Osttask () function, which actually throws the document::d Idreceivetask () function onto the main thread to run.

6. Is the process of processing the message on the main thread, Document::d idreceivetask () starts running on the main path. Finally, it also implements the processing of messages by dispatch and fire a "message" type of event.
。

So it's gotta be. The mechanism of Woker is to realize the message passing through the relay object, and then the message is processed by "message" event.
(Reproduced Please specify Source: Http://blog.csdn.net/codigger)
 
The implementation mechanism of WEB worker in WebKit