On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson <mike...@hotmail.com> wrote:
> Michael Nordman wrote: > > On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson <mike...@hotmail.com> wrote: > >> Threading: >> This is the unavoidable question ;-) How do you envision >> multiple threads accessing this shared context to be >> coordinated? >> > Nominally, they don't. In our design for chrome's multi-process > architecture, the global-script would only be shared within a single > 'renderer' process (in which all page's, and global-scripts, execute in a > single thread). > > This might not be the same in other browsers. I think you need to define > how concurrent access should be handled so it can be applied to f ex a > browser using a single process but a thread per top-level window. If I > understand correctly it would be something like letting only one thread call > inside the GlobalScript context at a time? > > Process boundaries: >> In this past discussion there have been several mentions >> about having to cluster "pages" inside the same process >> if they are to share data. >> Why is this so, and why can't shared memory or proxied >> objects be an option for browsers doing process >> separation? >> > A multi-process browser vendor probably *could* proxy all script calls to a > truely global context across all 'renderers'... but that is not required in > the proposal... and is probably even discouraged. > > One of the motivations for doing this is webapp performance. Proxying all > script interactions across the page/context boundary works against that. > Also synchronization issues get much more complicated. > > Implicit in the proposal is that a global-script is very inexpensive to > interact with. > > Certainly, the ideal case is that they are in the same process. Using > proxies is coming back to serialization all over again, although > transparent. What I was commenting was the (seemingly widespread) notion > that it is impossible to share data between process, which is not true. > There is nothing stopping an implementation from using direct calls whenever > process sharing is possible, and falling back to proxies in cases when > processes need to be different. > With this stated, I'd like to throw out a question on what do you want the > most - max performance in 100% of cases, but redundant GlobalScript > contexts, or max performance in most cases and singular GlobalScript > contexts? > I don't think any UA is realistically going to do this for v1. But sure, the door should be left open for in the future. (The initial proposal allows for both, btw.) > Also, what about shared memory (I'm assuming everybody knows what this is) > - apart from being non-trivial stuff, are there any specific drawbacks that > renders it not useful for this case? > I think it being non-trivial is the only issue. When it becomes necessary for performance reasons, I'm sure people will start looking at this. J
