932402 - Shumway: need support for creating multiple globals in a worker

Status: RESOLVED INVALID

(Core :: DOM: Workers, defect)

Description

[Till Schneidereit [:till]]

To be able to run multiple properly isolated player instances in the same worker thread, we need the ability to create sandboxed globals for them.

AFAICT, this should be straight-forward to implement by essentially doing what the shell does for `newGlobal`.

Note that for bug 930908, we'll get a custom worker type for Shumway anyway, so adding this as a non-standard API is not an issue.

Comment 1

[Bobby Holley (:bholley)]

Note that there are a number of architectural assumptions in workers that we have to be careful about when adding multiple globals.

What kind of wrappers are you planning on using? If these sandboxes have security or isolation guarantees, I'm going to veto any solution that uses transparent CCWs.

In the DOM bindings meeting, we've been coming to grips with the fact that we're probably going to need XrayWrappers on workers, which means generalizing some of our security wrapper machinery. We should most definitely coordinate here.

Comment 2

[Till Schneidereit [:till]]

(In reply to Bobby Holley (:bholley) from comment #1)
> Note that there are a number of architectural assumptions in workers that we
> have to be careful about when adding multiple globals.

I'm aware. I'm currently doing some experimentation to get a better picture of all of this, but will certainly ping you once I have specific questions.

> 
> What kind of wrappers are you planning on using? If these sandboxes have
> security or isolation guarantees, I'm going to veto any solution that uses
> transparent CCWs.

They do have isolation guarantees, yes. I'm not entirely sure yet whether we can use non-transparent CCWs and still implement the required semantics, however: Flash allows SWFs from different domains to grant access to each other dynamically, and I don't know if we can express this capability with non-transparent wrappers. Again, I'll talk to you about specifics once I have a better picture, myself.

> 
> In the DOM bindings meeting, we've been coming to grips with the fact that
> we're probably going to need XrayWrappers on workers, which means
> generalizing some of our security wrapper machinery. We should most
> definitely coordinate here.

We absolutely should, and it's good to hear that this is needed for other reasons, too.

Comment 3

[Bobby Holley (:bholley)]

(In reply to Till Schneidereit [:till] from comment #2)
> > In the DOM bindings meeting, we've been coming to grips with the fact that
> > we're probably going to need XrayWrappers on workers, which means
> > generalizing some of our security wrapper machinery. We should most
> > definitely coordinate here.
> 
> We absolutely should, and it's good to hear that this is needed for other
> reasons, too.

Note that we've backed away from Xrays on workers, for now. Also note that ejpbruel is currently working on multiple-globals-on-workers.

Comment 4

[Till Schneidereit [:till]]

(In reply to Bobby Holley (:bholley) from comment #3)
> Note that we've backed away from Xrays on workers, for now. Also note that
> ejpbruel is currently working on multiple-globals-on-workers.

Most excellent, thanks for the heads-up! I just talked to Eddy and it looks like we'll be able to expose multiple globals fairly simply once his work in bug 757133 has landed. What to do about wrappers is a different question altogether, of course.

Comment 5

[Bobby Holley (:bholley)]

Keep in mind that Eddy's work involves a lot of simplifying assumptions (since interaction between the scopes can only happen using the SM debug APIs). It's not a given that what you want to do will necessarily be acceptable - we'll have to flesh it out and talk more about it.

Comment 6

[Till Schneidereit [:till]]

(In reply to Bobby Holley (:bholley) from comment #5)
> It's not a given that what you want to do will necessarily be
> acceptable - we'll have to flesh it out and talk more about it.

Yes, I'm absolutely aware. I don't at all expect some trivial patch on top of Eddy's work to get us where we need to be. :)

Comment 7

[Till Schneidereit [:till]]

Not needed anymore, as we're going to use an e10s process instead of a worker.