# e10s status update
As requested, here's an update on multiprocess Servo. The following areas
must, but do not yet, run over IPC in a multiprocess scenario and should be
considered frozen:
* Developer tools (#6745): Awaiting re-merge after an intermittent test
failure.
* Resource task (#6586): Still blocked on the OpenSSL upgrade. As I
understand things, the plan of record is to install OpenSSL headers for
Gonk on the bots.
* Display list (#6795): Review in progress.
The following areas have now been made multiprocess-safe and I think should
be unblocked:
* Image cache task.
* Canvas and WebGL.
# Rules of the road for the content process
Once all of the messages have been made e10s-safe, I will begin submitting
patches to move {script, layout} and everything else into separate
processes—"content" and "chrome" respectively. Everything that is in the
content process will be severely restricted using the native OS sandboxing
infrastructure. As a rule of thumb, in the content process:
* Don't open non-temporary files.
* Don't access any OS resources (clipboard, etc).
* Don't access the GPU. (Note that Azure can access the GPU on some
architectures.)
For a precise list of allowed syscalls on Linux, check out the list here:
https://github.com/pcwalton/gaol/blob/master/platform/linux/seccomp.rs#L137
You can work around this restriction by having the constellation spawn new
threads to perform privileged operations. (Note that the constellation
needs to do this; script doesn't have a high enough privilege level to
spawn privileged threads directly.) You should make the communication
messages serializable and deserializable and use IPC channels when you want
unprivileged and privileged code to interact. Thankfully, `serde`'s macros
and `ipc-channel` make this very easy for you. In general, all you need to
do is tag your messages with #[derive(Deserialize, Serialize)]` and use
`IpcSender<T>` and `IpcReceiver<T>` for communication instead of
`std::sync::mpsc`. In Servo, there is generally no need to mess with manual
serialization and deserialization code, worry about OS primitives, or even
write in a separate "serialization" or "protocol description" language, as
the compiler integration handles all of this for you.
Thanks for helping Servo become a multiprocess engine!
Patrick
On Sun, Jul 26, 2015 at 1:25 PM, Patrick Walton <pwal...@mozilla.com> wrote:
> Here's the status on a per-patch basis:
>
> * Storage task (#6746): Bouncing due to what I believe to be an
> ipc-channel bug whereby Unix socket file descriptors sometimes get
> unexpectedly closed on Linux. Investigating now.
>
> * Developer tools (#6745): Not reviewed yet. (Josh Matthews is the
> reviewer here.)
>
> * Image cache task (#6597): Bouncing due to seemingly random failures of
> IPC sending during the CSS tests on Linux. I cannot reproduce these
> failures. They may be the same thing as #6746.
>
> * Resource task (#6586): Blocked on an OpenSSL upgrade. We need a Hyper
> fix for URL serialization, but Hyper has upgraded to a later version of
> OpenSSL which has landed some changes that cause linking errors on Gonk.
> Matt Brubeck has a PR open for the OpenSSL upgrade (#6740) which is blocked
> for the same reason.
>
> * Display list: Need to submit a new patch here to fix a few issues in
> serialization. In particular, linked lists are not serialized properly, but
> serde has support for linked list serialization now, so the PR here will
> just remove our old broken hacks around this missing serde feature.
>
> Note that as soon as each of these land I think we should unblock the area
> in question immediately. The type system ensures that, even though we will
> not be a multiprocess browser engine until all of the pieces land, each
> individual area will remain e10s-safe as long as new cross-process channels
> are not added (and no forbidden syscalls are being performed in the content
> process, but reviewers should be watching for this too). So, for example,
> there are outstanding PRs to add new functionality to WebGL that I think
> should be allowed to proceed now that canvas and WebGL e10s functionality
> has landed.
>
> A related issue that I should point out is that we are beginning to have a
> major performance issue for some workloads (anything that crosses process
> frequently, including the resource task) in Servo. This is relevant to the
> current situation because it can lead to intermittent timeouts on tests
> that stress certain parts of the system. The reason for this is because
> serde has not yet merged the bincode support, so we are forced to use JSON
> for the time being. Although serde has a very fast JSON serializer, it is
> still obviously very slow compared to bincode. I have worked around this by
> using shmem where I can, but we will still continue to hit this until serde
> has merged bincode. Fortunately, Erick Tryzelaar, the maintainer of serde,
> has a working branch for bincode and an outstanding PR to rework the API to
> allow for this, so I do not expect this to continue for long.
>
> Patrick
>
> On Sun, Jul 26, 2015 at 8:35 AM, Lars Bergstrom <larsb...@mozilla.com>
> wrote:
>
>> What is left to land these patches, and whom do you need help from to get
>> these finished?
>>
>> I’m fine with freezing these interfaces if it’s for a week or so, but
>> during the last few weeks this change has uncovered some pretty big holes
>> in Cargo, the WPT tests, our CI configuration, etc. I guess I’m primarily
>> curious if you have a sense for how long it will take to get this landed
>> and whether there’s anything we or the Rust team can do to speed things
>> along.
>> - Lars
>>
>>
>> On Jul 24, 2015, at 11:03 PM, Patrick Walton <pwal...@mozilla.com> wrote:
>>
>> Oh, I forgot to mention 2D canvas and WebGL. This implies a moratorium on
>> all new canvas or WebGL functionality.
>>
>> Patrick
>>
>> On Fri, Jul 24, 2015 at 8:45 PM, Patrick Walton <pwal...@mozilla.com>
>> wrote:
>>
>> > As most people know by now, I'm having a lot of trouble getting
>> > multiprocess Servo landed :) Much of the trouble here is that changes
>> keep
>> > coming in that are not multiprocess safe, and as multiprocess tends to
>> > trigger random test failures it ends up being a never-ending losing
>> battle
>> > to keep up with the churn while simultaneously fixing test failures.
>> >
>> > I propose *freezing the interfaces* for the following sections of Servo
>> > until they have been made multiprocess-safe:
>> >
>> > * Developer tools
>> > * Core script/constellation communication:
>> ScriptListener/ScriptControlChan
>> > * Pipeline and constellation setup
>> > * Image cache task
>> > * Resource task
>> > * Display list
>> >
>> > By "freezing the interfaces" I mean that no new channels (anything in
>> > `mpsc`) may be added, no more data types may be added that go over those
>> > channels, and no more variants in those enums (i.e. messages) may be
>> added.
>> >
>> > Additionally, I would like to propose that any instance of boxed trait
>> > objects being sent over channels requires signoff that they are not
>> > crossing over a chrome-content boundary. If they are, I think they
>> should
>> > be also blocked from landing until the relevant parts of Servo have been
>> > converted to be e10s-safe.
>> >
>> > I apologize if this seems heavy-handed, but it's been very difficult to
>> > land this stuff. I'm working around the clock to try to lift these
>> > restrictions, but I don't know how much longer it will take.
>> >
>> > Thoughts?
>> > Patrick
>> >
>> >
>> _______________________________________________
>> 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
>>
>
>
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
