5 ms·

The State of Servo, Mozilla's parallelized Rust browser

114 points by bazzargh 14y ago

pilgrim689 14y ago
I wonder what the roadmap of both Servo and Rust are? What's the vision? Why Rust? Why Servo?
- kibwen 14y ago
  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 https://github.com/mozilla/rust/wiki/Doc-project-FAQ Language FAQ: https://github.com/mozilla/rust/wiki/Doc-language-FAQ https://github.com/mozilla/rust/wiki/Doc-language-FAQ
- deleted 14y ago
  [deleted]
- bazzargh 14y ago
  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.html http://robert.ocallahan.org/2007/09/parallel-browsing_13.htm... That's kindof the big picture.
  - davedx 14y ago
    Interesting. This was written before Google released Chrome. How parallel is Chrome, exactly, compared to the kind of browser described in this blog post?
    - pcwalton 14y ago
      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.
      - hoppipolla 14y ago
        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-related-browsing-contexts http://www.whatwg.org/specs/web-apps/current-work/#unit-of-r...
        bzbarsky 14y ago
        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.
        hoppipolla 14y ago
        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.
        bzbarsky 14y ago
        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.
  - elteto 14y ago
    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 :)
    - bzbarsky 14y ago
      When Chrome first came out it didn't have a super-mega-fast-quick JS engine. Certainly not by today's standards. ;)
kibwen 14y ago
For reference, here is the triumphant result of Servo's first ever image rendering test: http://i.imgur.com/LLfDL.png 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/ea53b5e800bcf31a95f84fe51cf81c9dd3feca77 https://github.com/mozilla/servo/commit/ea53b5e800bcf31a95f8...
MatthewPhillips 14y ago
This is fascinating. I recommend browsing the source. It makes me, conversely: 1) Want to learn Rust and 2) write my own browser engine.
- joshmoz 14y ago
  Why don't you help with Servo? We're always happy to have new hackers helping out.
  - betterth 14y ago
    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?
    - jerf 14y ago
      A well-reported Rust novice's reaction to Rust would probably be a useful data point for that team at this point.
    - ktizo 14y ago
      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.
      - marshray 14y ago
        It's true. The language is still in flux and the folks on the #rust channel are all very patient with my newb questions.
  - davedx 14y ago
    How could I get involved or find out what kind of work could be done? Could you drop me an email, davedx@gmail.com :)
augustl 14y ago
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 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.
- SkyMarshal 14y ago
  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.
sho_hn 14y ago
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.
- daeken 14y ago
  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.
  - sho_hn 14y ago
    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.
    - evmar 14y ago
      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.)
      - 14y ago
_delirium 14y ago
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 http://news.ycombinator.com/item?id=3501980 (v0.1, January '12) http://news.ycombinator.com/item?id=3792403 http://news.ycombinator.com/item?id=3792403 (March '12) http://news.ycombinator.com/item?id=3774075 http://news.ycombinator.com/item?id=3774075 (v0.2, March '12)

114 points by bazzargh 14y ago

pilgrim689 14y ago

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

kibwen 14y ago
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 https://github.com/mozilla/rust/wiki/Doc-project-FAQ Language FAQ: https://github.com/mozilla/rust/wiki/Doc-language-FAQ https://github.com/mozilla/rust/wiki/Doc-language-FAQ
deleted 14y ago
[deleted]
bazzargh 14y ago
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.html http://robert.ocallahan.org/2007/09/parallel-browsing_13.htm... That's kindof the big picture.
- davedx 14y ago
  Interesting. This was written before Google released Chrome. How parallel is Chrome, exactly, compared to the kind of browser described in this blog post?
  - pcwalton 14y ago
    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.
    - hoppipolla 14y ago
      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-related-browsing-contexts http://www.whatwg.org/specs/web-apps/current-work/#unit-of-r...
      - bzbarsky 14y ago
        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.
        hoppipolla 14y ago
        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.
        bzbarsky 14y ago
        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.
- elteto 14y ago
  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 :)
  - bzbarsky 14y ago
    When Chrome first came out it didn't have a super-mega-fast-quick JS engine. Certainly not by today's standards. ;)

kibwen 14y ago

For reference, here is the triumphant result of Servo's first ever image rendering test: http://i.imgur.com/LLfDL.png 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/ea53b5e800bcf31a95f84fe51cf81c9dd3feca77 https://github.com/mozilla/servo/commit/ea53b5e800bcf31a95f8...

MatthewPhillips 14y ago

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

joshmoz 14y ago
Why don't you help with Servo? We're always happy to have new hackers helping out.
- betterth 14y ago
  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?
  - jerf 14y ago
    A well-reported Rust novice's reaction to Rust would probably be a useful data point for that team at this point.
  - ktizo 14y ago
    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.
    - marshray 14y ago
      It's true. The language is still in flux and the folks on the #rust channel are all very patient with my newb questions.
- davedx 14y ago
  How could I get involved or find out what kind of work could be done? Could you drop me an email, davedx@gmail.com :)

augustl 14y ago

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 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.

SkyMarshal 14y ago
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.

sho_hn 14y ago

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.

daeken 14y ago
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.
- sho_hn 14y ago
  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.
  - evmar 14y ago
    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.)
    - 14y ago

_delirium 14y ago

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 http://news.ycombinator.com/item?id=3501980 (v0.1, January '12) http://news.ycombinator.com/item?id=3792403 http://news.ycombinator.com/item?id=3792403 (March '12) http://news.ycombinator.com/item?id=3774075 http://news.ycombinator.com/item?id=3774075 (v0.2, March '12)