On Tue, May 26, 2009 at 5:00 PM, Sam Weinig <sam.wei...@gmail.com> wrote:
> On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek <j...@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 the difference, i.e. there is only one set of JavaScript bindings for 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). > > -Sam > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
