We're currently testing -M but not -M -S, e.g. see: https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/steps.yml#L46
I don't think there's any great reason for not testing sandboxing as well as multiprocess. We're testing multiprocess for Mac and Linux, not Windows as multiprocess isn't supported there. Alan. On Tue, Aug 2, 2016 at 9:47 AM, Jack Moffitt <j...@metajack.im> wrote: > > First, is multiprocess and sandboxing actively supported? > > I tested this right before the nightly release, and it was working > fine and didn't seem to have bad performance. Note that you can run -M > or -M and -S, but not -S by itself (which doesn't make sense). Also > note that -M and -S probably don't work on Windows or Android > currently. > > > Is Servo tested with the "-M -S" options? > > We do not have automated testing of these yet. > > > What's the status of the sandbox? > > Should work on Mac and Linux, but hasn't been audited. > > > Is there any reasons for these options to not be turned on by default? > > They should be, although I think we wanted to fix perf issues running > the WPT suite and get all the platforms working first. We should > probably test both configurations. > > > Do we want to enable "-M -S" for browserhtml? Would that help? > > I wanted to have this for the nightly, but didn't have time to test. > If it works and has decent performance we can switch to having these > be on. > > > I'd like to understand what is not part of the sandboxed content process. > > I guess compositor code and anything GPU and window related is not > > sandboxed so it runs in the main process. > > How does a sync call to localStorage work in a sandboxed process? > > Where is networking code executed? > > The thing that lives in the extra processes (which are sandboxed) are > the script and layout threads. Right now each script/layout thread > gets its own process (and I think any pipeline which shares the same > script thread). > > Eventually we'll want to have each extra process contain some number > of pipelines. So that is script+layout but for arbitrary numbers of > domains. > > The constellation, networking, graphics, etc all live in the root > process which has privileges. > > > > I'm trying to understand the relation between a constellation, iframes > > and a sandboxed process. I would naively expect to have one process > > per constellation, but apparently, it's one process per iframe. If I'm > > not mistaken, today in browserhtml, we have only one constellation. I > > imagine in the future there would be one sandboxed process per > > constellation, one constellation per group of tabs of the same domain, > > and one constellation for browserhtml. > > There is only one constellation. A constellation owns a set of > pipelines which then form a tree of pipelines. It is only these > pipelines that live outside the main process. > > Eventually we'll probably experiment with where resource caching > threads and such go. > > Here's a link to the deck I presented in London which has pretty > pictures of what the design should be: > > https://docs.google.com/presentation/d/1ht96DBAynx7dbL2taDAzNHs78QWeKvyzrVV1O-cDQLQ/edit?usp=sharing > > jack. > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
