[whatwg] Global Script proposal.

[Jeremy Orlow]

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?
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090818/b20c4a38/attachment-0001.htm>