The implementation mechanism of Web worker in WebKit

Web Worker is a JavaScript running in the background, independent of other scripts, without affecting the performance of the page. This is a standard of HTML5, implementation of the browser for Wokrer launched a new thread, thus realizing the function of asynchronous operation;

The following is a simple example of Woker, where a worker object named "worker" is created in the HTML page with Worker.js as the source file, and a message is sent to the worker thread through the worker.postmessage () interface; The worker thread adds the two data that the JSON format passes, and then sends the message back to the main thread of the page JS running through the PostMessage () interface, and the main thread processes the message sent by 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 executing JS is simply divided into the following steps:
1. When executing to var worker = new Worker (' worker.js '), construct the Webcore::jsworker object (jsbbindings layer) and the corresponding webcore in the kernel: Worker object (WebCore module);
2. During the construction of the Jsworker object, the asynchronous loading process is initiated according to the initialized URL address "worker.js";
3. Execute worker.postmessage () to send JSON formatted message data to the worker thread; Since this time, the worker thread has not yet been created, so the message data is placed in a temporary message queue;
4. Worker.js after the asynchronous load completes, the worker thread is created and started, and the message data in the temporary message queue is copied to the woker corresponding Workerrunloop message queue;
5. After the worker thread is created, the message stored in the message queue of workerrunloop is processed;
6. Woker thread sends the message to the main thread;
7. The main thread message worker thread sends a message that executes onmessage ();
Of course, if, after a round of messages, we use the button buttons in the example to trigger the message asynchronously, then the execution 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;

In order to understand the entire implementation mechanism, we first look at WebKit internal worker related classes, where the worker corresponds to the main page of the ' Worker ' object in JS (the main thread), and dedicatedworkerthread represents the worker thread; Workermessagingproxy associates the Worker object with the worker thread, enabling the message relay between the main thread and the worker thread; Dedicatedworkerthread controls the execution of scripts in the Worker.js file in the worker thread through Workerscriptcontroller; The browser creates a separate virtual machine environment (VM) for the worker thread;

Here's a look at the detailed process:
1. Worker.js asynchronous loading process, such as loading is the creation of Webcore::jsworker and Webcore::worker objects, and is the asynchronous loading process, will not block the subsequent JS execution, This is also why the first call to Worker.postmessage () will occur when the worker thread has not yet been created;

2. The worker thread is created as shown in. As can be seen, when the worker.js loading is complete, WebKit will create Dedicatedworkerthread objects through the Transit object workermessagingproxy and start workerthread; Workermessagingproxy Keep pointers to dedicatedworkerthread objects;

3. The process by which the main thread sends messages to the worker thread is as follows, and when JS executes to "worker.postmessage ()", it is eventually mapped to Jsworker via the JS main thread virtual machine::p ostmessage () function, The message is added to the worker's message queue through the brokered object Workermessagingproxy, and if the worker thread is not created when the message is sent, we see a M_queueearlytasks object that temporarily saves the current message. The worker thread is created and then transferred to the formal message queue; otherwise, the message is added directly to the official message queue of the Workerrunloop administration;

4. The process of processing messages in the worker thread is as follows, which is the process of starting "onmessage ()" in worker.js; We can see that the Dedicatedworkthread object in its own thread environment runloop out the execution of the data in the message queue, and executes by Eventtarget::d Ispatchevent () distributes and fire a "message" Type of event to be implemented;

.

5. Is the process of sending messages in a worker thread, which is also done through workermessagingproxy, and finally triggers the document::p Osttask () function, which actually will document::d Idreceivetask () function is thrown into the main thread to execute;

6. Is the process of processing messages on the main thread, Document::d idreceivetask () begins execution on the main course, and eventually the message is processed by dispatch and fire a "message" type of event;
，

Therefore, in general, the mechanism of Woker is to implement the message through the relay object, and then through the "message" event to complete the processing of the message;

----------------------------------------------------------------------
Original address:http://blog.csdn.net/codigger/article/details/40581343
----------------------------------------------------------------------
The implementation mechanism of Web worker in WebKit