W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] Passing more than JSON data to workers

From: Drew Wilson <atwilson@google.com>
Date: Thu, 17 Dec 2009 10:26:59 -0800
Message-ID: <f965ae410912171026p42c95081s13e9e06cc0b20ea@mail.gmail.com>
That was my point earlier - for this to work, if you post getX and setX over
separately, they need to share a closure otherwise they don't work.

Realistically, given Javascript's dynamic nature, you need to copy
everything reachable via the function's scope chain, and recursively copy
everything reachable via any reachable function's scope chain. In effect,
copying a function to worker context means bringing over the entire
reachable heap. Anything else you try to do is going to break in subtle ways
when something in the source context's scope chain isn't in the destination
context's scope chain.

I understand that we might like to treat code running in a worker as if it
were running in a same context as the parent page, so you could pass all the
same things to it that you could pass to any Javascript function, but the
situations are not identical - the only way something like this would be
feasible would be by adding limitations (i.e. not copying over the scope
chain of a function) that IMO fundamentally break Javascript semantics ;
once you do that, you might as well just use the existing string + eval()
mechanisms.

-atw

On Thu, Dec 17, 2009 at 2:06 AM, Oliver Hunt <oliver at apple.com> wrote:

> On Dec 17, 2009, at 10:03 PM, Boris Zbarsky wrote:
>
> > On 12/17/09 12:48 AM, Boris Zbarsky wrote:
> >> It seems very difficult to me to come up with a "function cloning"
> >> solution that won't break in subtle ways when such functions are passed
> >> to it...
> >
> > I should clarify this.  It seems to me eminently possible to clone
> functions that only reference local (declared with var) variables and their
> arguments.  And maybe explicit |this| access; not sure.
> >
> > As soon as you're talking anything else, the situation gets very
> complicated, it seems to me.  That includes implicit property access on the
> global object.
> >
> > To make that clearer, consider these two functions, defined at global
> scope:
> >
> >  var x = 1;
> >  function f() {
> >    return x;
> >  }
> >  function g() {
> >    return Math;
> >  }
> >
> > If I understand your proposal correctly, passing f to a worker would pass
> across a function which always returns 1.  Passing g to a worker would do
> what?  Pass across a function that always returns the Math object from the
> web page scope?  If not, then how is Math different from x, exactly?  If
> yes, then why are we baking anything at all in at pass time?
> >
> > How is the f() example above affected if x is bound to an object, not to
> a number?
>
> I think a more interesting case is the relatively common idiom of closures
> for access protection, eg.
>
> function MyObject() {
>    var x;
>    this.setX = function(_x) { x = _x };
>    this.getX = function() { return x }
> }
>
> What should worker.postMessage(new MyObject) do if we were to try and
> serialise the functions? obviously you don't want them each to have
> (effectively) separate closures, and you can't just substitute their
> containing scope with the global object.
>
> > -Boris
>
>
> --Oliver
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091217/b57ee25c/attachment-0001.htm>
Received on Thursday, 17 December 2009 10:26:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC