Skip to content

Meeting 2015 02 23

Jump to bottom
Josh Matthews edited this page Feb 23, 2015 · 1 revision

Servo Meeting 2015-02-23

Agenda items

Attending

  • jack, pcwalton, simonsapin, jdm, kmc, mbrubeck, larsberg, manish, ms2ger

Rust in gecko

  • jack: Status? Media team was in-channel asking about container format muxers. Tracking bug? People can CC on it. (bug number goes here) Other thing - what are the Windows rust story requirements? Debug info with their tools?
  • larsberg: They don't want to ship msys, so in order to ship we want to break the standard library dependency on msys.
  • jack: Are there Rust bugs open for that?
  • larsberg: I've been asked to wait until after 1.0 to open the issue.
  • SimonSapin: Is this related to XP support?
  • larsberg: No, we don't need to worry about XP or tier-2 platforms like Sparc, as long as the Rust components are optional at build time.
  • jack: I'll ping Rust people to start tracking this, even if they aren't working on it yet.

MP4 demuxer

  • pcwalton: I was talking with roc about why they want to rewrite the MP4 demuxer, and it's because of synchronous I/O. That's great except Rust doesn't have a story for async I/O yet, and we're going to need one. MIO https://github.com/carllerche/mio is great but MIO just dropped Windows support.
  • jack: Can we just create a task and do blocking I/O off-thread?
  • pcwalton: Gecko media wants to move away from one-thread-per-video because of scalability, pages with hundreds of media streams. They want to multiplex multiple videos onto one thread
  • kmc: Does Gecko have its own nonblocking I/O layer? We might want to interface with that.
  • pcwalton: A lot of the infrastructure required is the same as for streaming, like propagating E_WOULD_BLOCK up. It may not be bad, but I want to make sure any libraries we use can set O_NONBLOCK and don't panic when they see E_WOULD_BLOCK. MIO has been driving a lot of these requirements already.
  • jack: What is MIO?
  • pcwalton: It's a non-blocking async I/O library in Rust; there was a talk at the Rust SF meetup this week that's on Air Mozilla. Right now it's the leader for nonblocking I/O support in Rust
  • kmc: It's a layer over POSIX-style, and they say in the future you could build a layer over Windows APIs.
  • jack: Could you just call poll/select on Windows?
  • pcwalton: It's there but it doesn't scale.
  • jack: It scales enough for this.
  • pcwalton: True. We're not trying to do C10k.
  • kmc: Can we convince them to maintain a Windows select backend even if it's not that fast?
  • pcwalton: You can talk to Carl about that. Plugabble back-ends might make sense. What Carl wants someone to do is write a separate rust-iocp and then a higher-level library that abstracts over MIO and rust-iocp. And we need other libraries to support non-blocking I/O gracefully, which MIO is already driving.
  • kmc: As I understand it, it's very hard to design a nice API over both IOCP and the Unix way. I like the idea of just using select() on Windows.
  • pcwalton: Yeah, the best anyone has done so far is to make everything single-threaded and callback-based, like uv.

More Rust in Gecko discussion

  • jdm: Another thing that came up was the Safe Browsing code in Firefox which is apparently occasionally unsafe and crashy: http://logs.glob.uno/?c=mozilla%23developers&s=19+Feb+2015&e=19+Feb+2015&h=rust#c1164049
  • larsberg: I strongly suspect that once Rust gets in gecko there's going to be a bunch of rewriting.
  • mbrubeck: Windows XP is not Tier 2. Don't have separate builds for it. If we want to turn on features for Windows, they need to run on XP, too.
  • pcwalton: Or keep old Gecko code around. That's something vlad suggested.
  • mbrubeck: Switch at runtime? Otherwise we'd need separate builds for XP users, which we don't have. Or don't ship the feature on Windows at all. If we don't want to ship to Windows, we can skip this whole story...
  • pcwalton: Maybe not that hard to build something that compiles on XP but is broken. If we're keeping the gecko code around, just compile on XP and switch at runtime. Also, not herculean effort to get Rust running on XP. Condvars.
  • kmc: Cross-compilation, or do we need to get the whole LLVM toolchain running on XP?
  • mbrubeck: Yes. Just a single windows build, built on a 2003 server or something.
  • kmc: Things like condvar detected at runtime?
  • larsberg: [old man linker hack war stories]

Extracting selector matching

  • SimonSapin: Done, just wanted to mention. People wanted to use selector matching outside of servo. We already had a set of traits for abstracting the tree representation, so it wasn't too hard to do. I extracted the matching code and it's a separate library (rust-selectors). Just landed earlier today. The API of that library is not pretty, but we can improve it later. Also have written to the users forum in Rust about writing something using it to manipulate HTML/XML trees. I'm not going to work on it myself.
  • jack: I've wanted this for writing simple commandline tools, great! Anybody using it?
  • SimonSapin: Multiple requests; unclear how many want to work on it.
  • kmc: Multiple people doing webscraping with h5ever. Not sure if anybody has implemented their own DOM type yet, but wouldn't surprise me.

Gonk

  • larsberg: Gonk is here. Manishearth put out some heroic efforts to automate our previously-manual build process. It runs on the Flame; we haven't checked any other devices. There's documentations in an in-tree README file. I also have a carefully-crafted tarball that avoids the need to pull all of the B2G repos. I'm talking to the B2G people about whether we can distribute that. Hopefully in the near future we'll have some sort of easy snapshot so you can build in less than several hours.
  • jdm: What exactly happens when you run it?
  • larsberg: It basically boots up Gonk and B2G, but kills the normal B2G process and launches Servo instead. It's a "bare metal Servo" but without the mozbrowser API we can't actually run Gaia. There's no keyboard, home screen, etc. Hopefully now that the build is reproducible, more people including people on the B2G team can start working on getting more pieces running.
  • SimonSapin: Is there a simulator or something for people without devices?
  • larsberg: We haven't worked on that yet. Right now the graphics stack works only with the Flame hardware; there are some missing pieces to make it compatible with QEMU. Michael Wu doesn't think it should be too hard.

Cargo bugs

  • jack: If you are unhappy / have issues, please open bugs. Make sure they are tracked in https://github.com/servo/servo/issues/2853
  • larsberg: One problem is that we have trouble coming up with minimal test-cases for bugs that happen in Servo, and without test cases they get closed. But please do open the bugs and we need to push on them.
  • jack: I'll get 662 reopened.
  • jack: What are the main pain points?
  • larsberg: Lots of bugs of the form "it rebuilds too much" or "it doesn't rebuild enough." Native dependencies; difficultiy figuring out what files you can touch to force a particular piece to rebuild.
  • Simon: The cargo clean command takes a -p argument, which is a way to force a rebuild.
  • larsberg: OS X cross-compilation gets broken a lot since there's no automated testing of it on the Rust/cargo side. We can request a new builder.
  • Manishearth: Given the amount of intermittent failure for Rust, adding another blocking builder would add to that pain.
  • kmc: That needs to be fixed ASAP. I hope people are looking into it.
  • mbrubeck: Shared target directories would help a lot, like letting us split up our test harness into multiple crates.
  • jack: Definitely.
  • mbrubeck: Also, doesn't require reproduction, etc.

Rust upgrade

  • larsberg: Alpha 2 is here. We knew there would be another big rustup coming. The big question is old_io, which is still required. Should we do a rustup now and then another one when new io is finished? Or wait until week of March 2 when we can move fully to new io? I'm a bit wary of a partial io upgrade?
  • Manishearth: I think we should be doing the minimum possible for rustups.
  • Simon: I agree.
  • larsberg: Okay. I'll make a snapshot and kick off a rustup to something around alpha 2.
  • jack: Hopefully we won't have to close the tree. Should we get some of these long-standing PRs merged first?
  • pcwalton: Yes, my goal this week is to get everything rebased. Brace yourselves: reviews are coming.
  • jack: Can we wait a week before starting the rustup, so we can recover from the last rustup?
  • larsberg: Yes please.
  • pcwalton: That would help with completing quarterly goals like transforms, animations.
  • jack: So we'll be starting the rustup around March 2, to give everyone a whole week for rebases and reviews. If you're a reviewer, please try to get it done by then.
  • Manishearth: People could start now on upgrading dependencies.
  • jack: Yeah. And some have already been changed to use Travis.
  • Manishearth: Ping me if you want help setting up dependencies on Travis.

linux/glutin

  • jack: Working on parallel paint and there's a lot of stuff on Linux with basic usability. Get weird things like half-screen paint, scrolling, switching desktops, etc. being broken. Other people seeing this?
  • pcwalton: Some issues on OSX, but I fixed a major one there around scrolling. The scrolling in glutin is also not smooth. And major issue if you build with optimizations then you get a whitescreen and hang to an obj-c call with the wrong ABI. Pulling a new glutin will fix some of the OSX ones, but not Linux.
  • jack: Seems like we should pay some attention to these.
  • pcwalton: Don't think they're servo issues; think they're glutin. We need to be pushing on it. One alternative is miniservo, but lots of our dev experience is gated on how well glutin works. Definitely worth investing time in that.
  • jack: I've started filing bugs; if others could, that would help. We've gotten in the habit of complaining in IRC and I think that is not effective. If we're gonna have nightlies, this would be a disaster.
  • manishearth: Should we set up a metabug for non-rust/cargo bugs we're blocked on? Or just having them float around and wait for maintainers?
  • jack: Maybe for big stuff - glutin, hyper, etc. Seems fine. Very useful for one place for the Rust/cargo devs at.
  • larsberg: FYI, they take a lot of time (half hour a day or so) to keep up to date.
Clone this wiki locally