[whatwg] asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness
Boris Zbarsky
bzbarsky at MIT.EDU
Tue Aug 6 19:11:19 PDT 2013
On 8/6/13 5:58 PM, Ian Hickson wrote:
> One could imagine an implementation strategy where the cloning is done on
> the sending side, or even on a third thread altogether
The cloning needs to run to completion (in the sense of capturing an
immutable representation) before anyone can change the data structure
being cloned.
That means either serializing the whole data structure in some way
before returning control to JS or doing something where you start
serializing it async and block until finish as soon as someone tries to
modify any of those objects in any way, right?
The latter is rather nontrivial to implement, so UAs do the former at
the moment.
> Serialising is hard to do async, since you fundamentally have to walk the
> data structure, and the actual serialisation at that point is not
> especially more expensive than a copy.
Right, that's what I said above... ;)
> Parsing is easy to do on a separate worker, because it has no dependencies -- you can
> do it all in isolation.
Sadly, that may not be the.
Actual JS implementations have various "thread-local" data that objects
depend on (starting with interned property names), such that it's not
actually possible to create an object on one thread and use it on
another in many of them.
>> For instance, how would you serialize something as simple as the following?
>>
>> {
>> name: "The One",
>> hp: 1000,
>> achievements: ["achiever", "overachiever", "extreme overachiever"]
>> // Length of the list is unpredictable
>> }
>
> Why serialise it? If you want to post this across a MessagePort to a
> worker, or back from a worker, why not just post it?
>
> var a = { ... }; // from above
> port.postMessage(a);
This in practice does some sort of serialization in UAs.
> Assuming by "Firefox Desktop" you mean the browser for desktop OSes called
> Firefox, then, why not just do this in C++?
Let's start with "because writing C++ code without memory errors is
harder than writing JS code without memory errors"?
> I don't understand why you
> would constrain yourself to using Web APIs in JavaScript to write a browser.
Simplicity of implementation? Sandboxing of the code? Eating your own
dogfood?
I can come up with some more reasons if you want.
-Boris
More information about the whatwg
mailing list