Charles, I've read your paper and ultimately I think my goal may be somewhere along the lines of making the DOM tree thread-safe by applying my research in iterators and lock-free data structures.
A tricky question: What can be parallelized here? What level of atomicity is required by scripts. Does Javascript even provide a means to do any kind of concurrency control? Any locking mechanism? The paper suggests javascript knows nothing about multithreading (Disclaimer: I'm NOT a javascript expert). If not, what level of implicit atomicity does the browser need to provide for javascript? That is to say, can we allow two functions manipulating the same DOM interleave on a per statement basis? I'm a bit worried that there are limitations in the language itself that make this problem extend beyond a consistent iteration problem. Do you have an example or two of race conditions you've seen in Internet Explorer? Heck, if you can provide me with javascript code samples that demonstrate issues so I can better understand what's going on that would be 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
