The State of Servo, Mozilla's parallelized Rust browser | Hacker News Reader

The State of Servo, Mozilla's parallelized Rust browser

groups.google.com

114 pointsbazzargh39 comments

If you're like me and have no idea what Servo is, this seems to be a good summary.

http://www.2ality.com/2012/02/servo.html

Tl;dr: A brand new browser, implemented with a language called Rust, aims to be small and good at utilizing CPU cores.

More specifically, a brand new layout engine for Firefox, to eventually replace Gecko, with better concurrency and safety enabled by Rust. Firefox will still use the same Javascript engine.

For reference, here is the triumphant result of Servo's first ever image rendering test: http://i.imgur.com/LLfDL.png

This was about a month ago, so perhaps the state of the art[1] has progressed since then.

Yes, I'm pretty excited to watch Servo develop. :)

[1] https://github.com/mozilla/servo/commit/ea53b5e800bcf31a95f8...

This is fascinating. I recommend browsing the source. It makes me, conversely: 1) Want to learn Rust and 2) write my own browser engine.

Why don't you help with Servo? We're always happy to have new hackers helping out.

For someone who knows Rails and front end web development (and a bit of Java and a touch of C++), what could I offer to Servo? Learning Rust and helping would be fun, but would such novice to Rust be welcome to the project?

A well-reported Rust novice's reaction to Rust would probably be a useful data point for that team at this point.

The language was only officially unveiled in 2010, so I don't think you will have too many problems with impatient rust greybeards pouring scorn on the new fledgling whippersnappers yet.

It's true. The language is still in flux and the folks on the #rust channel are all very patient with my newb questions.

How could I get involved or find out what kind of work could be done? Could you drop me an email, davedx@gmail.com :)

Not sure if anyone has contacted you yet, but you could also contact the team via the mailing lists:

dev-servo: https://lists.mozilla.org/listinfo/dev-servo

rust-dev: https://mail.mozilla.org/listinfo/rust-dev

The latter is by far the livelier one, but I don't think they'd have any complaints if you used it to ask about helping out on Servo. :)

I'm actually not sure what version of Rust the Servo folk are using... in which case the Rust you're reading may be very different from the language's current iteration. I believe work on Servo started immediately after 0.2 was released, back in March. 0.3 ought to be out sometime this week. And I still wouldn't exactly recommend learning either version, because most of the tutorials and docs still refer to 0.1. :P If you want help learning or want to help out, the devs hang out in #rust on moznet during California working hours.

We're using the bleeding edge master builds of Rust. Our work on Servo informs the direction we want to take Rust, and vice versa. Servo has been really valuable to help us determine whether the language features really work out in practice.

What git id should I use. I tried using the master of rust to build the master of servo and got:

    make -C src/rust-harfbuzz RUSTFLAGS="-L ../harfbuzz/src/.libs/"
    make[1]: Entering directory `/tmp/servo/build/src/rust-harfbuzz'
    rustc -L ../harfbuzz/src/.libs/ /tmp/servo/src/rust-harfbuzz/harfbuzz.rc -o libharfbuzz.dummy
    make[1]: Leaving directory `/tmp/servo/build/src/rust-harfbuzz'
    RUSTFLAGS="-L ../mozjs/" CFLAGS="-I../mozjs/dist/include" \
                    make -C src/rust-mozjs
    make[1]: Entering directory `/tmp/servo/build/src/rust-mozjs'
    rustc -L ../mozjs/ /tmp/servo/src/rust-mozjs/js.rc -o libjs.dummy
    /tmp/servo/src/rust-mozjs/rust.rs:16:0: 16:8 error: expected item but found 'resource'
    /tmp/servo/src/rust-mozjs/rust.rs:16 resource rt_rsrc(self: {ptr: *JSRuntime}) {
                                        ^~~~~~~~
    make[1]: *** [libjs.dummy] Error 101
    make[1]: Leaving directory `/tmp/servo/build/src/rust-mozjs'
    make: *** [src/rust-mozjs/libmozjs.dummy] Error 2

Sorry about that; we're fixing this as I write this. We removed resources from the language recently; less is exponentially more.

Here are some HN discussions from earlier this year, for those confused about the what/why of Rust:

http://news.ycombinator.com/item?id=3501980 (v0.1, January '12)

http://news.ycombinator.com/item?id=3792403 (March '12)

http://news.ycombinator.com/item?id=3774075 (v0.2, March '12)

This is scary to me:

> I think it is important that these libraries get rewritten in Rust over time, starting with the most Web-facing code --- Harfbuzz and stb_image.

Text shaping is _hard_ and not something you want to NIH on.

That ignores what Servo actually is. The entire point of it is that it's written from the ground up in a modern, typesafe language. External libs take away from that and add security and performance concerns.

Fair enough. I appreciate that bold ambition, and I realize it's an R&D project :). It just has a little bad negative aftertaste to it in this context, considering that Harfbuzz has been a really good example of a body of code that solves a hard problem and has been collaborated on and adopted by many different parties. Going NIH on it, even with noble intent and explicit technical reasons, just feels like a step backward, and like trying to do too many things at once.

I guess what it comes down to is whether what Servo is justifies that lack of pragmatism: That's what it'll have to prove.

FWIW, there are two Harfbuzzes: the old one that is derived from Qt code that many people have collaborated and hammered on over the years, and the new one that Mozilla uses that was rewritten from scratch by one person. The new one is likely better-written overall (the author generally knows what he's doing), but it's not really true that Harfbuzz (as Mozilla uses it) has been collaborated on by many parties or has had as much (or any) security analysis.

(I worked on relevant pieces of Chrome, which has has a bunch of security issues due to bugs in the older, presumably more vetted, Harfbuzz, so I don't have a lot of confidence of code in this area. Lots of indexing into arrays.)

There's been plenty of that in our version too.

e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=701637

Daeken's point below is spot on, but I thought I'd add that, if we don't have the manpower to rewrite everything in a safe language, we can go out of process and sandbox like Chromium does. (In fact, the plan is to sandbox even the safe code.) Of course, that's plan B; plan A is to parallelize the entire stack, top to bottom.

Rust is interesting to deal with some hard problems keeping a multicore program safe and efficient, but I'm sure sandboxing will provide a better tradeoff for a lot of things (and as sho_hn points out, Harfbuzz correctly embeds a lot of domain knowledge from multiple cultures). C can be locked down pretty tight, see for example ZeroVM which restricts it to pure functional code.

Text shaping is hard? How about a browser? If these guys think they've got something innovative, more power to them. We got this comment a lot back when we started Chrome, but fortunately we didn't let it stop us :-)

Yes, browsers are hard!* That was sort of the point: If you're trying to crack a problem like that, you might not want to also try to solve text shaping on the side, because you may not have the time to do it properly. There's a lot more out there than English, and OpenType can do quite a lot.

* = I hail from KDE, and am good friends with some of the people who originally made the browser engine you're using today in Chrome :).

Like I said, the success of the project doesn't depend on the feasibility of rewriting HarfBuzz. We're quite pragmatic about using external libraries; in fact, Rust's FFI is the best FFI I've ever used in any non-C/C++ language. Robert's point is simply that the end result will be better if we can make a memory-safe, parallel HarfBuzz along the way, written in a language that improves programmer productivity.

You removed the rest of the context.

> in Rust to ensure the language can do it

When creating a language you want to write as many things as possible in it to vet the design. See Go, e.g. http://golang.org/src/pkg/image/jpeg/fdct.go.

JPEG is a good benchmark because it is a bottleneck, heavily optimised with SIMD, and still amenable to some parallelisation. That doesn't apply to text layout.

I wonder what the roadmap of both Servo and Rust are? What's the vision? Why Rust? Why Servo?

Here are the Rust FAQ pages, which are sadly not prominently linked from rust-lang.org:

Project FAQ (most applicable to your question): https://github.com/mozilla/rust/wiki/Doc-project-FAQ

Language FAQ: https://github.com/mozilla/rust/wiki/Doc-language-FAQ

Mozilla's Robert O'Callahan blogged back in 2007 on reasons why you'd want a parallel browser, and how C++ as an implementation language was a barrier to progress: http://robert.ocallahan.org/2007/09/parallel-browsing_13.htm...

That's kindof the big picture.

Interesting. This was written before Google released Chrome. How parallel is Chrome, exactly, compared to the kind of browser described in this blog post?

WebKit, like all engines, is fundamentally single-threaded. Of course, there can be some parallelism added to specific components--in the case of Chrome, multiple tabs (to be more accurate, multiple origins) can execute in parallel--but there's a scalability limit to how far a single-threaded design can take you.

I think multiple "units of related browsing context" [1] would be more accurate; unless I am wrong Chrome uses at most one process per event loop and has one event loop for each set of browsing contexts that can reach each other via the DOM. This means that e.g. an alert in tab A will block scripts in tab B if B.opener == A.

AFAICT IE has a somewhat different design; it seems to really be much closer to "one process per tab", which presumably means that they incur some IPC overhead when different tabs in the same unit of related browsing context have to communicate.

[1] http://www.whatwg.org/specs/web-apps/current-work/#unit-of-r...

You're somewhat wrong. Chrome will put browsing contexts that normally can't reach each other via the DOM on the same event loop (and in the same process) if it decides it's got too many renderer processes spawned already. Once it does that, they can try to reach each other via the DOM if they have window names.

Oh, so 1:1 between processes and event loops? Doesn't that mean that something blocking in one tab (alert(), sync XHR) might will block tasks in any entirely unrelated tab that just happens to share a process/event loop? That seems rather unexpected.

I can't speak to the exact event loop behavior; I haven't tested it.

Even if you have only one main event loop per process, spinning nested event loops (e.g. the way Firefox does for alert and sync XHR) would let you do things in one tab while another is blocked on an alert or whatnot. I just don't know whether Chrome does that.

It's funny how the first comment is about browsers lacking a "super-mega-fast-quick JS engine". I bet that was one happy Chrome user when it first came out :)

When Chrome first came out it didn't have a super-mega-fast-quick JS engine. Certainly not by today's standards. ;)

Reply on news.ycombinator.com