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

Reply via email to