W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Sync API for workers

From: Lon Ingram <lawnsea@gmail.com>
Date: Fri, 7 Sep 2012 10:53:14 -0500
Message-ID: <CAM7HOSBgXrA5c5Px-QO5sVpvcF0CLNrwuVwpOkLHW12gdodjXQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Andrea Marchesini <amarchesini@mozilla.com>, David Bruant <bruant.d@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
> On Thu, Sep 6, 2012 at 7:18 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> That is certainly an interesting use case. I think another interesting
>> use case is being able to write synchronous APIs in workers whose
>> implementation uses APIs that are only available on the main thread.
> I understand the concept, but I'm having trouble coming up with useful
> examples.  Can you give one?

I have one: virtualizing the API of the main thread in a worker. In Treehouse
[1], we sandbox untrusted JS in a worker, where we provide a virtual browser
interface - including the DOM (using a hacked up fork of jsdom). This allows us
to (1) restrict the guest code to a subset of the DOM, and (2) interpose on
privileged operations.

At present, we present a synchronous interface to the virtual DOM and then
replicate changes back to the actual DOM in the main thread asynchronously. This
works surprisingly well, but has some limitations.

First, concurrent access to a given DOM node from more than one worker is a
difficult problem, so we punt and require that a node may appear in at most one
virtual DOM. Second, we do not know how to virtualize some synchronous methods
and properties, such as window.prompt.

I believe that a synchronous messaging API would allow us to overcome both of
these issues.

[1] Treehouse PDF:

Lon Ingram
Received on Friday, 7 September 2012 15:53:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC