On Thu, Jan 7, 2010 at 1:10 PM, Charlie Reis <cr...@chromium.org> wrote:
>
>
> 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.
>
There are 2 exceptions in Chrome and IE (and maybe Opera?): Cookies and
LocalStorage.
The spec attempts to solve both of these with a "Storage Mutex" which
basically must be taken on the first access to a cookie or localStorage and
must not be released until the current script execution ends. The network
stack is also supposed to take this lock when reading or writing cookies.
The single mutex is shared across the entire browser.
A LOT of time and effort has been spent on coming up with a better answer,
but there are a lot of constraints to the problem (not all of them
technical) and I've pretty much given up hope of anything better replacing
it in the spec.
That said, we have no intention of being the first to implement the storage
mutex in Chrome, and I know of no one else intending to implement it either.
So until then, cookie and localStorage access is simply racy (in Chrome,
IE, and maybe Opera).
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
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
