[webkit-dev] GlobalScript in WebKit

Darin Fisher darin at chromium.org
Mon Nov 30 14:48:55 PST 2009


On Mon, Nov 30, 2009 at 2:30 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> On 30.11.2009, at 14:05, Dmitry Titov wrote:
>
>  That also pretty much means if we won't have SharedScript, we'll need to
>> explore other opportunities toward efficient sharing of code and data which
>> does not make people to write a multithreaded UI as SharedWorker solution
>> would do. We have practically zero positive response to SharedWorkers being
>> used this way. Granted, this is "just one company" but the devs here are
>> good and came from variosu other companies so the limited unscientific poll
>> kind of shows the outcome...
>>
>
> This makes me wonder if there is any positive experience using
> SharedWorkers for this elsewhere - or any better use cases for it.
>
> At the moment, it seems that technical issues around shared workers's
> implementation in WebKit haven't all been resolved yet, and that
> GlobalObject could be a better replacement for the same use case anyway.
> Dropping one for another is in the spirit of successful experimentation -
> what do you think?
>
> - WBR, Alexey Proskuryakov
>
>

Just a note:

In Chrome, a SharedWorker is reachable from any WebKit process, whereas a
SharedScript would only be reachable within a WebKit process.  This is an
interesting distinction, and I can imagine some use cases for SharedWorker
that SharedScript could not address.  (This distinction arises because we
did not want to build a script proxy between WebKit processes as that would
be quite costly.)

For example, suppose you wanted to have only one instance of a web app
responsible for manipulating a database or communicating with a server.
 There's no guarantee that multiple instances of a web app would all run in
the same WebKit process.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091130/4b382817/attachment.html>


More information about the webkit-dev mailing list