Javascript running and browser multithreading __java

Javascript Running and browser multithreading

2006.12 lu_yi_ming (_at_) sina.com



_ The purpose of this article

Web page HTML structure and JAVASCRIPT programs are becoming more and more complex, it is necessary to organize ideas.

This article just want to tidy up the train of thought, a lot of details not necessarily accurate.


_ Question Details

Now a Web page contains multiple iframe (Frame), every iframe has windows (specifically in this article, window in the DOM window,ms windows and Windows in X window is represented by window), each Window can have setinterval, as well as settimeout, in addition window.document there are many element, each element can have an event, and these event can be bubble to B Ody.

Question 1. Within a window, is event and window.setinterval/window.settimeout parallel?
Question 2. is Javascript parallel between windows?
Question 3. is Javascript parallel between windows that belong to the same process?
Question 4. If there is parallel existence, what kind of parallelism? Does the browser simulate multiple threads for each window or window, or does it take advantage of the multithreading of the operating system itself?
Question 5. If there is a parallel existence, how to solve the mutex in Javascript operation, signal?


_ Preliminary understanding

After some simple research (because lazy, not to read the Firefox source code), have the following preliminary understanding.

For IE, with Spy + + analysis, found that the increase in the page of the Iframe does not cause the increase in the thread, also can not cause the increase of child WINDOW. Therefore, the Iframe and window in IE are implemented internally by Shell.explorer (COM components in Shdocvw.dll), possibly in a separate thread, probably in the thread that the window belongs to. Further, Javascript inside the window of all Iframe in window is not parallel. Further, combined with network transmission, if a iframe.src assignment, the thread of Javascript should notify another thread (in this article, the communication thread) to send HTTP requests to the server. After the communication thread receives a full HTTP packet from the server, it will hand the packet over to the thread responsible for the display (the intermediate link may have a thread responsible for parsing the HTML), and the thread (or parsing thread) displays the Javascript on the side of the running page, such as document.write ()。 and constantly drawing the screen. In this HTTP packet processing, no other events such as the setinterval of windows of the Iframe are processed. After you have processed one thing, you will select an expired start run (call) in the internal timer/timeout queue.

So, if the Javascript of an Iframe window is stuck in a dead loop, all the IFRAME within this thread will stop responding, and new data received from the server will be shelved.

Multithreading in IE. Pressing ctrl-n on IE, or running window.open (), will open a new window, and from Spy + +, a new thread will be added to manage the new window. But no more new threads are added, stating that all windows in a process share a communication thread. That is, the communication process manages all TCP Connection. The object pointer returned with window.open () can access the new Windwo, and can access the various data in the window of the Iframe under it, or even call the functions in it, just to notice the difference in the stack. After testing, if two-thread Javascript accesses the same data at the same time, such as having a window.setinterval specified function to access a variable of an element in a window, or modifying a property, one of the functions returns Javascript Exception: Deny access, which means that the browser is aware of mutual exclusion in the internal implementation.

Based on the above understanding, for IE, there should not be multiple threads in the window of all Iframe in a window, and there is no Javascript parallelism. Of course, there is no function like sleep. Blocking a Javascript function, such as a specific ActiveX, can cause the entire WINDOW to pause accordingly.

There is also a discovery about IE, Window.setinterval is not implemented with Wm_timer.

About Firefox, on Windows, with Spy + + analysis, every Iframe in the page is implemented with a WINDOW. But all windows, including other Tab-opened windows, belong to one thread. But across the tab, accessing one data at a time across the browser window also triggers JavaScript Exception: Denial of access, which means that Firefox's Javascript is likely to be within a Tab range and not parallel. It could be that Firefox has a separate thread for each Tab to run Javascript. Anyway, the final behavior should be similar to IE, it is estimated that.

On Linux (FC6) to start Firefox, with gdb attach in, found that when the new Web page will add a lot of threads, but the page display stability after a period of time, the number of threads will be reduced. This may also be because the thread task that is running Javascript is done.


_ Preliminary Conclusions

1. Within a WINDOW of IE, Javascript is a single-threaded operation within a Tab of Firefox.
2. If you want to implement JavaScript synchronization between the various Iframe on the page, you should use Window.setinterval instead of suspending a JavaScript.
3. When you cross windows on IE or Access data across the tab on Firefox, be careful to resolve the Exception caused by thread mutex with try catch.