On Thu, Jan 7, 2010 at 10:18 PM, Fady Samuel <[email protected]> wrote:
> 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? > If chromium ever achieves process separation for origin security, then a shared monolithic cache would probably be a bad idea. > 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 <[email protected]> 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/[email protected]/msg07788.html >> >> <http://www.mail-archive.com/[email protected]/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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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: [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
