[whatwg] Global Script proposal.

[Dmitry Titov]

On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson <mikewse at hotmail.com> wrote:

> [2] As I understand it, the new GlobalScript construct is
> a context that can be shared by all browsing contexts in
> the user agent.
>

It can, but with a caveat: in case of user agents that are multi-process, in
some cases there will be more then one Global Script instance. For example,
lets say there is a process for the tab opened for site S1 and there is
another process with a tab for site S2. if S2 has iframe pointing to S1, the
page in that iframe will get a separate instance of the Global Script since
it can't access the one which is created for the tab showing S1. It is
equivalent to running the same app in different browsers...

So it's across browser contexts in the same process.


> Questions
> ---------
>
> Threading:
> This is the unavoidable question ;-) How do you envision
> multiple threads accessing this shared context to be
> coordinated?
>

The Global Script would run on the main thread of the browser - same one
where all the JS on visible pages is executing. It can (and should) use
Workers to unload work from ui tread but its use cases are all around
running synchronously on the same thread as UI pages of the application, so
that it's possible to keep event handlers in it or update the shared UI
state synchronously (for example, user selects an image in a document - the
toolbar buttons with image operations become active).


>
> 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?
>

Since there is a direct JS access to the Global Script on the main thread of
the browser, that would require something like synchronous JS IPC. While
theoretically possible, it is very complicated to retrofit the existing
browsers for that; it can have issues with performance of JS (especially JIT
types of JS engines) and it also has disadvantages of any sync API that may
block on a remote resource (since another process is independent and may
have its own reasons to block).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090818/7403dd8c/attachment.htm>