- From: Mike Wilson <mikewse@hotmail.com>
- Date: Tue, 18 Aug 2009 21:20:52 +0200
Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson <mikewse at 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? 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? Best regards Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090818/ad7fda21/attachment.htm>
Received on Tuesday, 18 August 2009 12:20:52 UTC