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
