- From: Aaron Boodman <aa@google.com>
- Date: Tue, 18 Aug 2009 12:32:05 -0700
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson<mikewse at hotmail.com> wrote: > 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? I think it is likely impractical for windows that have javascript access to each other to be on separate threads. The relationship between the global script and pages accessing it is similar to a parent windows and an iframe that are on the same origin, or to a window and a popup window on the same origin. Objects should be able to be freely passed across both sides. For example, the global script should be able to have a JavaScript object graph which represents some application state and share it (by reference) with its clients. I don't see how it is realistic to do this when the windows are separated by a thread boundary. Therefore, I would say it is totally valid for a UA to put a bunch of windows that want to use the same global script URL in different threads, but it should group them by thread. Each thread should get its own global script that is shared among the windows that are on that thread. - a
Received on Tuesday, 18 August 2009 12:32:05 UTC