On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel <[email protected]> wrote:
> 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. > Javascript absolutely expects to be single-threaded, and Javascript programmers expect it even more so. > > 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 >
-- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
