On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie <b...@google.com> wrote:
>
>
> On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel <fadysam...@gmail.com> 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.
>
>
That's correct. However, Fady is referring to an observation in my paper
that race conditions are actually possible in cross-window JavaScript calls
in Internet Explorer and Opera. Those browsers allow pages in different
windows to run in separate threads, even if they are from the same site and
can easily call into each other. From my tests, it appears that IE at least
tries to avoid race conditions by blocking one page until the other
finishes, but it allows the race if a deadlock occurs.
You can test this fairly easily by calling a long-running function in
another page that is repeatedly calling the function itself. In Opera, both
pages' threads will be in the function at once. In IE, the first page will
be blocked until the second finishes, unless the second page tries to call
back into the first page at the end of its function. That would be a
deadlock, so instead they allow the data race.
I don't think the spec allows for these races-- as people have mentioned,
JavaScript has a single-threaded, run-to-completion model. Chromium avoids
races by only putting pages that can't communicate on different
threads/processes.
Charlie
>> Thanks,
>>
>> Fady
>>
>> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis <cr...@chromium.org> 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 <pkast...@google.com>wrote:
>>>
>>>> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel <fadysam...@gmail.com>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: chromium-dev@googlegroups.com
>>>> View archives, change email options, or unsubscribe:
>>>> http://groups.google.com/group/chromium-dev
>>>>
>>>
>>>
>>
>> --
>>
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
