Javascript running and multi-thread Browser

Javascript running and multi-thread Browser

2006.12 lu_yi_ming (_ AT _) Sina.com

_ Purpose of this Article

The HTML structure of web pages and javascript programs become more and more complex. It is necessary to sort out the ideas.

This article just wants to sort out some ideas, and many details are not necessarily accurate.

_ Problem details

Now a webpage contains multiple IFRAME (FRAME), and each IFRAME has a window (in this article, window refers to window in Dom, window in MS windows and window in X Window are represented by window), each window can have setinterval, and setTimeout, in addition, there are many elements in the too many Doc ument, each element can have events, and these events can always be bubble to the body.

Question 1. In a window, is the event parallel with window. setinterval/window. setTimeout?
Question 2: Is JavaScript between Windows parallel?
Question 3. Is JavaScript between windows of the same process parallel?
Question 4: What kind of parallelism does it mean if there is a parallelism? Does the browser simulate multithreading for each window or window, or does it use the multithreading of the operating system itself?
Question 5: If parallel processing exists, how can we solve the mutex and signal in Javascript running?

_ Preliminary understanding

After some simple research (because of laziness, I did not read the Firefox source code), I have the following preliminary knowledge.

For IE, spy ++ is used for analysis. It is found that adding IFRAME in the page does not increase the number of threads or subwindows. Therefore, IFRAME and window in IE are shell. explorer (shdocvw. the COM component in the DLL) is implemented internally, probably in a separate thread, probably in the thread to which the window belongs. Furthermore, the Javascript in all IFRAME windows in the window is not parallel. Further, combined with network transmission, if an IFRAME. SRC value is assigned, the thread where Javascript is located should notify another thread (the communication thread in this article) to send an HTTP request to the server. After receiving a complete HTTP packet from the server, the communication thread will hand over the packet to the display thread (a thread may be responsible for parsing HTML in the intermediate stage ), display the JavaScript code on the page, such as document. write (). And constantly draw the screen. In the HTTP packet processing process, other IFRAME window events such as setinterval are not processed. After one task is processed, an expired instance (called) will be selected in the Internal timer/timeout queue ).

Therefore, if the JavaScript code of an IFRAME window falls into an endless loop, all IFRAME in this thread will stop responding, new data received from the server will also be shelved.

Multiple Threads in IE. Press ctrl-N on IE or run window. open () will open a new window. From the perspective of spy ++, a new thread will be added to manage the new window. But no more new threads are added, indicating that all windows in a process share the communication thread. That is, the communication process manages all TCP connections. Use window. the Object Pointer returned by open () can access the new windwo, and can access various data in the IFRAME window under it, or even call the function, but you must pay attention to the different stack. After testing, if the Javascript of both threads accesses the same data at the same time, such as window. setinterval specifies the function to access the variable of an element in a window, or modify the attribute, one of the functions will return JavaScript exception: access is denied, note that the browser has noticed mutual exclusion in its internal implementation.

Based on the above understanding, for IE, there should be no multithreading or Javascript parallel in all IFRAME windows of a window. Of course, there will be no sleep or other functions. Blocking a JavaScript function (such as a specific ActiveX) may cause the entire window to be suspended.

We also found that window. setinterval is not implemented using wm_timer.

For Firefox, in windows, spy ++ is used for analysis. Every IFRAME on the page is implemented using a window. However, all windows, including the windows opened by other tabs, belong to one thread. However, cross-tab and cross-browser window access to a single data at the same time also triggers JavaScript exception: access is denied, indicating that Firefox's JavaScript is probably within a tab range and is not parallel. Firefox may open a separate thread for each tab to run JavaScript. Anyway, the final behavior should be similar to that of IE, which is probably the same.

Start Firefox on Linux (fc6) and use GDB attach. It is found that many threads will be added when the web page is opened. However, after the web page shows stable, the number of threads will decrease. This may also be because the Javascript running thread task is finished.

_ Preliminary conclusion

1. In a window of IE, JavaScript runs in a single thread in a tab of Firefox.
2. If you want to implement JavaScript synchronization between IFRAME on the page, you should use window. setinterval instead of suspending a JavaScript.
3. Cross-window on IE or cross-tab access to data on Firefox, use try catch to solve the exception caused by thread mutex.