Which brings me back to the original topic of replicated state. Is there any
reason not to have a single monolithic cache (or other similar state) across
all processes other than synchronization issues or fault tolerance?
I have a technique to give me a consistent, "snapshot" view of data
structures without actually creating a copy of the data structure (a form of
concurrent, robust iterator I'm calling a strongly consistent iterator). The
shared data structure itself can also be made fault tolerant despite being
shared.
That way, two site instances can share images, scripts, etc.
Thanks,
Fady
On Thu, Jan 7, 2010 at 4:49 PM, James Robinson <jam...@google.com> wrote:
> 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
