4 ms·

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

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