Is Servo going to employ a multi-process model like Chromium? I am afraid so which makes it very tough for embedding. I see cef_execute_process [1] and what not are not implemented. Are there plans to implement that far up the embedding API? Hopefully a single-process-yet-multiple-page/tab embedded servo is fully supported (unlike --single-process for CEF/Chromium).
Yes, Servo is going to go multi-process. There's a PR to do that already (though it needs a good amount of forward porting at this point).
It's hard to say about single-process mode; it'll stay maintained as long as someone's willing to do the maintenance. There isn't anything that's inherently multiprocess about the architecture (for example, there are basically no global variables anywhere in Servo), in any case, so I don't imagine it'll be hard to keep it running. I don't want to make any promises, though.
What are the benefits of multi-process over merely multi-threaded for a guaranteed memory- and thread-safe language like rust?
In the Chromium Multi-process Architecture design document[0] the benefits boil down to security and stability. While memory safety doesn't guarantee secure logic, it obviates a large class of bugs that a multi-process architecture is designed to counteract. While memory safety doesn't prevent deadlocks, it does completely prevent data race conditions.
You are right that process sandboxing is not as important for Servo, but it is important: 1) more defenses are more better, 2) Servo contains considerable amounts of C and C++ code and will for some time, 3) Even safe Rust has failure modes that can abort the process (primarily out-of-stack), and multiprocess provides recovery for when they happen.
It's important to emphasize that the Servo developers don't consider the fact that Rust is memory-safe to be an excuse to skimp on proven approaches to application security. Servo will still utilize multi-process architecture and sandboxing in order to provide defense-in-depth.
Remember that the goal of Servo is not just to be as safe as modern engines, but to be far safer (while also being twice as fast!).
> not just to be as safe as modern engines, but to be far safer
A worthy goal! However, I'm still concerned. If the project is sufficiently secure without multi-process, adding layers only increases the surface area for attack vectors. Sandboxing not only increases the surface area of your (now) multiple processes, but also introduces the OS layer as an arbiter of communication between them, which we can safely assume does not have memory safety guarantees (though is probably quite hardened).
Of course, the developers would not claim that Servo is "sufficiently secure" right now, especially since (as brson mentioned) it still includes C & C++ source. My point is, sandboxing can be a huge win in terms of security, especially for now; but any complex feature has tradeoffs and the efficacy of those tradeoffs may not continue to hold through the future and should remain open to consideration.
I don't see how a lack of sandboxing would decrease your attack surface, since you need to communicate with the OS somehow. A sandbox just moderates that communication.
I also don't understand "If the project is sufficiently secure without multi-process, adding layers only increases the surface area". The point of layers is that each one needs to be breached in order to craft a full exploit. If one layer is sufficiently secure without multi-process then in the worst case your defense-in-depth is merely redundant, regardless of the attack surface of the remaining layers (though obviously "sufficiently secure" is fairly impossible to prove).
If there is a bug in the mechanism used to ferry messages between the two processes, as that mechanism lives in the kernel, only that one mechanism needs to be breached to attack the computer: sometimes, "layers" are more like a "chain", which are only as strong as the weakest "link". (However, that is much less likely than an issue in the native GUI components, or the apparently non-negligible amount of unsafe C/C++ and JIT'd code used by Servo.)
That's essentially a detail of the Windows sandbox implementation. Servo's sandboxing story is Rust's gaol library [1], which has no support for Windows yet, but any multiprocess deployment on Windows would want to be accompanied by a sandbox utilizing those kinds of features.
Maybe I don't understand what you're asking, but when I think of embedding I think of the embedded component running in my process. Is that not the case with chormium? If it's its own process how do you interact with it?
It's entirely possible to make a multiprocess browser engine with a clean embedding API. WebKit does it, for instance. You can use WKWebView to pretty easily make your own process-per-tab browser.
Tangential question: Is it possible to parallelize constraint-based layouts?
Update: There is paper[1] describing layout parallelization with 80x performance increases. However, I'm not sure it works on constraint-based layouts, such as GSS[2].
> Ras Bodik’s group at the University of California Berkeley worked on a parallel browsing project (funded in part by Mozilla Research) that focused on improving the parallelism of layout. Instead of our approach to parallel layout, which focuses on multiple parallel tree traversals, they modeled a subset of CSS using attribute grammars. They showed significant speedups with their system over a reimplementation of Safari’s algorithms, but we have not used this approach due to questions of whether it is possible to use attribute grammars to both accurately model the web as it is implemented today and to support new features as they are added. Servo uses a very similar CSS selector matching algorithm to theirs.
It would certainly make for some curious history. I guess this was tongue in cheek?
EDIT: for those wanting context, WebKit started its life as fork of the KDE project's KHTML, and has gone on to supplant it. Having KDE ditch WebKit for Servo (no doubt with Safari and Chromium still using WebKit-based renderers) would be an strange state of affairs.
Not as strange as you think, perhaps. The KDE stack includes a component model called KParts, and embedding KHTML was always done via a KPart; this later allowed a WebKit KPart to co-exist. And in fact, there once was a working KPart to embed Gecko. It didn't really see widespread use, since Gecko wasn't all that attractive in the time frame.
If Servo continues to thrive, I'd be more surprised if no one attempts this.
The current state of browser engine embedding in Qt/KDE also isn't too rosy. Qt switched from wrapping WebKit to wrapping Blink, and the new wrapper is currently very skimpy on extension points, making it hard or impossible to put e.g. KDE's I/O stack (HTTP, SSL, cookies, etc.) between the renderer and the web. That's a level of integration both KHTML and the WebKit KPart did allow, so things have currently regressed a fair bit. I'm not familiar with the CEF API, but it might actually allow more than Qt WebEngine (currently) does.
Even if "strange" it would be a good state of affairs, since Servo is definitely going to have better performance (and I expect security). Plus it might help Debian to avoid some concerns they had recently regarding KDE packaging.
Doing everything in parallel is pretty much the point of the project. I'm not directly involved but I have been watching the project. There a few specific parts of layout that can't be parallelized[0] but pretty much every page [1][2] has work that can be done in parallel. The last batch of perf numbers I know of is from last November [3] and I'm unaware of any major perf regressions.
In benchmarks from last fall, Servo was twice as fast as modern engines for layout tasks even in single-threaded mode (and four to five times faster when using four cores). Who knows, this may regress as they implement more of the web platform, but Rust and Servo are also getting faster all the time. It will be fascinating to watch it progress over the next few years.
Unless you have CSS floats affecting the whole page, 90% of DOM elements in one parent element or other pathological cases my impression was that it is.
Small nit: The fact that most elements on the page are immediate children of one parent doesn't necessarily negatively affect parallelism. It only will if all those children are "display: inline". (For example, if your entire page is one giant paragraph hundreds of thousands of words long, then you won't get much parallelism out of layout. But you will if you have hundreds of thousands of separate paragraph elements, even if they're all siblings of one another.)
I always lamented that you can't make a command-line, programmable tool that is a fully robust implementation of the web. It would be very cool if this could enable it.
You could probably rig up a headless implementation, as CEF doesn't create its own windows if you run it in offscreen mode (as any widget embedder would do). Servo does have a "true" headless mode (headless.rs) as well that we use for running tests, though it's not exposed through CEF at the moment.
I'm sure that it's because Mozilla is comfortable with it. In reality, they don't owe us anything in particular. They chose a licence that works for them, is OSI Open Source(tm) approved and is compatible with a number of other licences (Apache, GPL, et al). Good enough.
The MPLv2 is a very nice license that deserves wider use.
MPLv2 is a weak (file-scoped) copyleft that avoids some of the provisions in (L)GPL that drive corporate lawyers raving mad, it's explicitly compatible with (L)GPLv2+ thus avoiding balkanization, and it does have a modern patent grant clause like ALv2/(L)GPLv3.
CEF is the API used to embed Webkit (now Blink). Servo is Mozilla's new research rendering engine, it's adopting the CEF API to make embedding easier for people.
Properly configured, Apache scales just fine. This site looks like it is running out of database connections. That's not something you can blame Apache for.
http://web.archive.org/web/20150513190529/http://blogs.s-osg...