There's a group at UC Berkeley that was (is?) working on a similar idea, you
can read about it here:
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
<http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/>With a discussion
that happened a few months back here:
http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html
<http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html>From
the discussion on webkit-dev I think the consensus was that it looked
interesting but that it wasn't clear that any practical benefit to be gained
in the short term.
There's probably simpler parallelism problems in the Chromium codebase to
tackle than those directly involving core layout and rendering code, perhaps
some of the caching layers.
- James
On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel <fadysam...@gmail.com> wrote:
> Well you can't know the precise set of locks you need obviously without
> "solving the halting problem". But maybe a static analysis can give you a
> conservative set of DOM trees you might access. Sorry, just thinking out
> loud I guess.
>
> Fady
>
>
> On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis <cr...@chromium.org> wrote:
>
>> The catch is that you don't know what locks you need to acquire in
>> advance, especially in the presence of things like eval. (And of course,
>> you can't roll back any JavaScript you've already run, so you would need to
>> know the locks in advance.)
>>
>> Charlie
>>
>>
>> On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel <fadysam...@gmail.com> wrote:
>>
>>> Hmm, I wonder if strict two-phase locking can be here to solve this?
>>>
>>> Fady
>>>
>>>
>>>>
>>>> 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
>>>>
>>>>
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
