Hacker News Reader

Comment by sanxiyn | Hacker News Reader

You may want to actually read this code. You can start by searching "LayoutStyleRecalc" at https://github.com/servo/servo/blob/master/components/layout.... Following is verbatim copy.

  // Perform CSS selector matching and flow construction.
  if traversal_driver.is_parallel() {
      let pool = self.parallel_traversal.as_ref().unwrap();
      // Parallel mode
      parallel::traverse_dom::<ServoLayoutElement, RecalcStyleAndConstructFlows>(
          &traversal, element, token, pool);
  } else {
      // Sequential mode
      sequential::traverse_dom::<ServoLayoutElement, RecalcStyleAndConstructFlows>(
          &traversal, element, token);
  }

View on HN

Hm, you may be lost if you don't have Rust IDE handy to jump around. Web cross reference for Rust code navigation is in development, but until that is ready, the next step is https://github.com/servo/servo/blob/master/components/layout...

parallel and sequential traverse_dom is generic traversal code which calls DomTraversal::process_preorder etc to do actual work. Here is lightly edited code:

  impl<'a, E> DomTraversal<E> for RecalcStyleAndConstructFlows<'a>
      where E: TElement,
            E::ConcreteNode: LayoutNode,
            E::FontMetricsProvider: Send,
  {
      fn process_preorder<F>(&self, traversal_data: &PerLevelTraversalData,
                             context: &mut StyleContext<E>, node: E::ConcreteNode,
                             note_child: F)
          where F: FnMut(E::ConcreteNode)
      {
          if !node.is_text_node() {
              let el = node.as_element().unwrap();
              let mut data = el.mutate_data().unwrap();
              recalc_style_at(self, traversal_data, context, el, &mut data, note_child);
          }
      }
  }

Note that everything in components/layout is servo-specific and not used by Stylo / Firefox. The code in components/style is shared, and the code that hooks it up to Firefox is in ports/geckolib/glue.rs (specifically Servo_TraverseSubtree).

What am I aiming for on this read? I'm assuming the hard parts are swallowed elsewhere, which is good. I'm a little surprised there are two methods for the traversal, depending on the parallel versus sequential. (I'd expect that could have been switched based on the "pool" parameter passed to a single method. No, I don't actually care.)

What do you consider hard parts? The actual magic is that there is no hard parts.

I haven't read it. That snippet just seemed odd to me.

The hard parts, in this case, would be in Rust, most likely. I'm assuming that flipping CSS to parallel is not a trivial process. I'm further assuming that there is still some sort of locking mechanism so that you don't fire off two parallel traversals at the same time. Or allow updates during a scan. (Or abort running scans if an update happens?)

Ah yes, parallelism (locking etc) part is entirely handled in generic Rust library (Rayon in this case), and not specific to Stylo at all. Here is where Stylo meets Rayon, https://github.com/servo/servo/blob/master/components/style/...

  //! Implements parallel traversal over the DOM tree.
  //!
  //! This traversal is based on Rayon, and therefore its safety is largely
  //! verified by the type system.

  /// A parallel top-down DOM traversal.
  ///
  /// This algorithm traverses the DOM in a breadth-first, top-down manner. The
  /// goals are:
  /// * Never process a child before its parent (since child style depends on
  ///   parent style). If this were to happen, the styling algorithm would panic.
  /// * Prioritize discovering nodes as quickly as possible to maximize
  ///   opportunities for parallelism.  But this needs to be weighed against
  ///   styling cousins on a single thread to improve sharing.
  /// * Style all the children of a given node (i.e. all sibling nodes) on
  ///   a single thread (with an upper bound to handle nodes with an
  ///   abnormally large number of children). This is important because we use
  ///   a thread-local cache to share styles between siblings.

It looks like Rayon is the same thing as Java's ForkJoinPool and parallel streams but with the neat trick (really, Rust's neat trick) that it can statically check that the code is safe to parallelise through the borrow checker.

Yes, that's a good summary.

I'm curious how well this plays with some of the fancier selectors. Adjacent sibling, in particular.

I'm also curious if this pretty much prohibits ever having a parent selector. I guess you could do a first pass through the styles to remove any DAG nature from them?

DOM element has parent and sibling pointer, so there is nothing particularly difficult about adjacent sibling, later sibling, or even parent selector as far as selector matching goes. Avoiding restyling becomes more tricky, but nothing serious. "Parent before child" is for CSS inheritance, not for selector matching.

For not-very-difficult details, read https://github.com/servo/servo/blob/master/components/select... searching for NotMatchedAndRestartFromClosestLaterSibling and HAS_SLOW_SELECTOR_LATER_SIBLINGS.

As soon as there are parent selectors, the pointers don't help. Specifically, if I restyle a parent, all children of parent need to be adjusted, right?

Siblings... I'm assuming there is nothing hard there. Positions, maybe?

I still don't see what problem parent selectors cause. Restyling parent happens anyway without parent selectors (say, by JavaScript), so it is handled. In https://github.com/servo/servo/blob/master/components/style/..., MustCascadeChildren is returned when you... must.

I was basically restating the restriction for the parallel scan. It goes from parent down so that during the scan you don't do something that causes the scan to have to restart.

I was also shooting from the hip for things I'm interested in, here. I'm not sure it matters. But, if on scanning, you pick relevant rules to apply based on the path to a node, then I could see some trickiness on having to consider both the top down and the bottom up paths to a node.

Siblings.., I don't think has this problem. Not sure why I thought it might.

And javascript is ultimately a different topic. So I wasn't worried about that here.

Coming back to this before I finally sleep.

I missed your point about selector matching and style application. I think that is ultimately where my hip shot missed on this. (I have never had to reserve the right to be wrong. Just to assume it. :)

I still feel there is some danger there, but I think that is just clinging to an initial shot. I am curious why rust's help was needed to get this, now. A basic thread pool seems like it would have been somewhat easy to wire up in any language.

Right, you don't need Rust to do this. In fact, Qualcomm did this with C++ and TBB in 2013, see http://dl.acm.org/citation.cfm?id=2442543. Rust does give you peace of mind that parallel styling won't be endless source of bugs, or worse, vulnerabilities.

Yeah, the key reason Rust is necessary here is that there is an insane amount of complexity in the heart of modern web engines. Injecting concurrency into the intersection of DOM and Layout is only realistic with some kind of static guarantees against data races, and Rust is the only tool I'm aware of to do that.

One neat thing is that we use rust-bindgen to walk C++ data structures, which extends Rust's concurrency guarantees into C++. We also have an FFI layer for invoking C++ code, and we have some careful static analysis of that callgraph from the entry points to be sure we're not mutating anything.

Reply on news.ycombinator.com