

The State of Servo, Mozilla's parallelized Rust browser - bazzargh
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.servo/nJJxEy1ehpE

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

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

------
kibwen
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...](https://github.com/mozilla/servo/commit/ea53b5e800bcf31a95f84fe51cf81c9dd3feca77)

------
MatthewPhillips
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
Why don't you help with Servo? We're always happy to have new hackers helping
out.

~~~
betterth
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?

~~~
ktizo
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
It's true. The language is still in flux and the folks on the #rust channel
are all very patient with my newb questions.

------
_delirium
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)

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

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

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

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

~~~
bazzargh
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...](http://robert.ocallahan.org/2007/09/parallel-
browsing_13.html)

That's kindof the big picture.

~~~
davedx
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
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
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...](http://www.whatwg.org/specs/web-apps/current-work/#unit-of-related-
browsing-contexts)

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

