[webkit-dev] SharedWorkers alternate design
jam at google.com
Tue May 26 18:32:05 PDT 2009
On Tue, May 26, 2009 at 5:00 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
> On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek <jam at google.com>wrote:
>> I agree that this approach is powerful. However there are (not too
>> frequent) situations when a port like Chromium wants to use both the WebKit
>> implementation and its own implementation, switching in runtime. For
>> workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
>> the interfaces that a worker object implements/uses. Since workers run in a
>> separate process from the renderer, we use our own implementations of these
>> interfaces that know about IPC etc. However once we're in the worker
>> process, we want to run nested workers in the same process, in which case we
>> want to use the WebKit implementation of these interfaces directly without
>> using Chromium's.
> This doesn't seem like a runtime choice, but rather a "use-time" choice.
> In the main context, you want use one implementation and in the worker
> context, another one. This to me implies two different objects with
> different names.
The code that deals with these objects doesn't (and shouldn't) need to know
workers, regardless of which process they're being used in.
> In non-multiprocess implementations of WebKit, these two objects could be
> the same object, and in multiprocess implementations (such as Chromium),
> they could be backed by different objects. This would not incur a runtime
> cost (and would be, subjectively of course, clearer).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev