[whatwg] asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness

[Boris Zbarsky]

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