Charles, this is awesome! Thanks! Fady
On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis <[email protected]> wrote: > Peter's right: as far as I understand, parsing, rendering, and script > execution are all expected to take place on a single thread of execution. > This includes any calls across multiple pages, which is why we place > "connected" same-site pages (those in the same unit of related browsing > contexts) in the same process. If one page calls a function in another > page, we don't want to allow data races. > > For more info on the decisions we've made about which pages go to which > process, see: > http://dev.chromium.org/developers/design-documents/process-models > > We also have a Eurosys 2009 paper on the topic: > http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf > > Hope that helps, > Charlie > > > On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting <[email protected]> wrote: > >> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel <[email protected]> wrote: >> >>> So a script cannot execute concurrently with the traversal of the DOM >>> tree? Could this be a performance bottleneck? >> >> >> Pretty much nothing in the renderer can execute concurrently with other >> things in the renderer. There have been academic papers published about >> trying to parallelize parts of web rendering, and some though experiments >> from various smart Mozilla and WebKit folks, but from what I've seen it's >> not promising. The web wasn't really designed with thread- or process-level >> parallelism on the part of the UA in mind. (Witness, for example, the >> horror of sync XHR, or how difficult it is to make alert()s not be >> renderer-modal.) >> >> In particular, it's fairly well-defined that script sees a coherent state >> as it executes, so unless you can solve the halting problem, there are >> pretty severe limits on how much you could parallelize script execution with >> other stuff. >> >> PK >> >> -- >> Chromium Developers mailing list: [email protected] >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
