[webkit-dev] SharedWorkers alternate design

[Jeremy Orlow]

It might also be worth bringing back up the unanswered quesiton of whether
this is even worth it for AppCache and LocalStorage.  As I mentioned, my
(less than scientific) testing indicated no.*  Maybe we're prematurely
optimizing here?  I definitely agree that virtual functions should be
avoided in code that's often called, but even AppCache doesn't really seem
to fit into that category.

Jeremy

* I have a test page that calls window.localStorage 100,000 times,
localStorage.setItem(foo, bar) 100,000 times, and localStorage.getItem(foo)
1,000,000 times.  All of these take under half a second, and the times don't
really change with my new implementation which does use virtual dispatch.


On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek <jam at google.com> wrote:

>
>
> On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>
>>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com>wrote:
>>>
>>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>>>
>>>>> The common case is definitely that we know whether we want the proxy
>>>>> (for IPC) or the implementation at compile time.  In some cases (like
>>>>> Chromium) this is not known until initialization time.
>>>>
>>>>
>>>>  What do you mean by "initialization time"?  Is it the case that you
>>>> know which one you want at each call site?  Or do literally want to make a
>>>> runtime choice based on state?
>>>>
>>>
>>> Well, I meant that we always want one or the other based on if the
>>> process is being used as a render process (i.e. sandboxed, running WebKit
>>> but with all DOM Storage calls proxied) or a browser process (i.e. running
>>> only selected parts of WebCore like the DOM Storage backend/implementation).
>>>
>>>
>>> Come to think of it (IIRC) all calls to the StorageBackend within the
>>> WebCore code should go through a proxy for Chromium.  The proxy will then
>>> call into Chromium's webkit bridge/glue, which will pass the message through
>>> the IPC layer, which will call back into bridge/glue code, which will be
>>> interacting with the real implementation.
>>>
>>> If that's true, then the implementation could be very explicitly split
>>> into 2 (with frontend code calling backend proxy code and vice versa) and
>>> single process implementations could simply typedef _____Proxy to _____Impl
>>> (or Implementation, or Base, or whatever you want to call it).
>>>
>>> ....or have I completely confused myself?
>>>
>>
>> To clarify, I'm saying that your question made me realize that we probably
>> can make a hard split between the frontend and backend code (i.e. what would
>> live in a sandbox and handle page rendering and what wouldn't live in a sand
>> box and store the actual DOM Storage data).  In single process cases where
>> there is no IPC barrier, and thus no proxy (and thus the actual
>> implementation code should be called directly) a typedef should bridge the 2
>> with no run time performance penalty.
>>
>> Darin, Sam, Maciej: does this alleviate your concerns?
>>
>> Michael, Drew, John: do you think it'd work for workers/appcache as well?
>
>
> This will work fine for appcache and localstorage, but isn't sufficient for
> workers since the same caller gets different objects depending on which
> process this is running in.  This doesn't happen for appcache and
> localstorage.
>
>
>>
>>
>> Everyone: have I completely missed something here?
>>
>> J
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/daa761ad/attachment.html>