loom
Servo
loom | Servo | |
---|---|---|
14 | 134 | |
1,896 | 26,075 | |
3.3% | 1.0% | |
6.8 | 10.0 | |
10 days ago | 3 days ago | |
Rust | Rust | |
MIT License | Mozilla Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
loom
- Turmoil, a framework for developing and testing distributed systems
-
An Introduction to Lockless Algorithms
> Mutexes are very cheap in the uncontended case
It was a while ago I was deep into this mess so forgive any ignorance–but–iirc the thread-mutex dogma[1] has many pitfalls despite being so widely used. Primarily they’re easy to misuse (deadlocks, holding a lock across a suspend point), and have unpredictable performance because they span so far into compiler, OS and CPU territory (instruction reordering, cache line invalidation, mode switches etc). Also on Arm it’s unclear if mutices are as cheap because of the relaxed memory order(?). Finally code with mutices are hard to test exhaustively, and are prone to heisenbugs.
Now, many if not most of the above apply to anything with atomics, so lock-free/wait-free won’t help either. There’s a reason why a lot of concurrency is ~phd level on the theoretical side, as well as deeply coupled with the gritty realities of hardware/compilers/os on the engineering side.
That said, I still think there’s room for a slightly expanded concurrency toolbox for mortals. For instance, a well implemented concurrent queue can be a significant improvement for many workflows, perhaps even with native OS support (io_uring style)?. Another exciting example is concurrency permutation test frameworks[2] for atomics that reorder operations in order to synthetically trigger rare logical race conditions. I’ve also personally had great experience with the Golang race detector. I hope we see some convergence on some of this stuff within a few years. Concurrency is still incredibly hard to get right.
[1]: I say this only because CS degrees has preached mutices to as the silver bullet for decades.
[2]: https://github.com/tokio-rs/loom
-
Should atomics be unsafe?
Of course atomics are absolutely essential for some of the libraries we take for granted, such as Arc and Tokio. But if you start reading the code and comments and issues and PRs around code like that, you'll see how much work it took to mature them to the point we can now rely on them. That's why tools like Loom exist.
-
Best tool to find deadlocks (in async code)
loom and shuttle can help you narrow down the problem.
-
Does Rust not need extra linting and sanitizing tools like C++?
Unless you are writing unsafe code, you generally don't need to use sanitizers. If you do write unsafe code, checking it with a sanitizer would be a great idea. Two most useful tools here I think are miri and loom.
-
The Deadlock Empire
https://github.com/tokio-rs/loom perhaps? It also models weak memory reordering, but takes some work to integrate into existing apps.
For triggering race conditions in compiled binaries, you could try https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo....
-
What could Go wrong with a mutex? (A Go profiling story)
There is Loom[1] (part of the Tokio project) for exhaustively testing multithreaded code. Though as far as I can tell it is designed for debugging threads, not async tasks.
[1] https://github.com/tokio-rs/loom
-
Cooptex - Deadlock-free Mutexes
That tool seems similar to https://github.com/tokio-rs/loom, insofar as detecting potential locking errors. These are useful during development, but could still miss production cases (as dev never perfectly matches production). This crate is meant to not have to worry about possibly deadlocking.
-
A bug that doesn’t exist on x86: Exploiting an ARM-only race condition
Rust doesn't catch memory ordering errors, which can result in behavioral bugs in safe Rust and data races and memory unsafety in unsafe Rust. But Loom is an excellent tool for catching ordering errors, though its UnsafeCell API differs from std's (and worse yet, some people report Loom returns false positives/negatives in some cases: https://github.com/tokio-rs/loom/issues/180, possibly https://github.com/tokio-rs/loom/issues/166).
- Multicore OCaml: April 2021
Servo
-
GitHub Sponsor the Servo Rust project!
Servo, the embeddable, independent, memory-safe, modular, parallel web rendering engine
- Bringing Exchange Support to Thunderbird
-
CSS for Printing to Paper
> Is there any easy to use/hack HTML layouting engine where I could experiment with custom CSS attributes and bridge that gap? Would anything from Servo be suitable?
Servo could be used for this. You'd want to add support for parsing the CSS properties themselves to the style crate in https://github.com/servo/stylo and then the layout implementation to the layout2020 crate in https://github.com/servo/servo. You do effectively get a whole browser though.
I'm currently working on building a lighter weight / hackable layout engine based on a combination of https://github.com/servo/stylo (for css parsing and selector resolution), https://github.com/DioxusLabs/taffy (for box-level layout) and https://github.com/pop-os/cosmic-text (for flow/inline layout). I expect to have something decent in around 6 months
Neither of these setups currently have any support for pagination though.
-
The Ladybird Browser Project
Great to see some competition still alive in browser engine development. See also Servo (previously part of Mozilla) https://servo.org/ - that and Ladybird are still very underdeveloped compared to every day browsers.
It's a huge shame that there are no nightly builds of ladybird to try out but I assume that's because they just don't want the bug reports (if everything doesn't work it's pointless getting random bugs filed).
-
Mozilla's Abandoned Web Engine 'Servo' Project Is Getting a Well-Deserved Reboot
I haven't messed with it yet but from looking into it, this should absolutely work.
https://github.com/servo/servo/wiki/Building-on-ARM-desktop-...
-
An open-source browser engine written in Rust
don't know, there was a downtime in 2021 and 22 but since 2023, contributions look back to where it was before .. https://github.com/servo/servo/graphs/contributors
-
Modern Java/JVM Build Practices
The world has moved on though to opinionated tools, and Rust isn't even the furthest in that direction (That would be Go). The equivalent of those two lines in Cargo.toml would be this example of a basic configuration from the jacoco-maven-plugin: https://www.jacoco.org/jacoco/trunk/doc/examples/build/pom.x... - That's 40 lines in the section to do the "defaults".
Yes, you could add a load of config for files to include/exclude from coverage and so on, but the idea that that's a norm is way more common in Java projects than other languages. Like here's some example Cargo.toml files from complicated Rust projects:
Servo: https://github.com/servo/servo/blob/main/Cargo.toml
rust-gdext: https://github.com/godot-rust/gdext/blob/master/godot-core/C...
ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/Cargo.toml
socketio: https://github.com/1c3t3a/rust-socketio/blob/main/socketio/C...
-
Top 10 Rusty Repositories for you to start your Open Source Journey
1. Servo
-
❓ Is Google flagging activity from Firefox and targeting uBlock?
It won't don't worry. There already are forks, for the worst case scenario. And Servo is on its way. Not yet ready, but it will be. Originally, from Mozilla kitchen.
-
Populating the page: how browsers work
To pain broad strokes, the layout phase (~= take the HTML, take the CSS, determine the position and size of boxes) is largely sequential in production browser engine today. Selector matching (~= what CSS applies to what element) is parallel in Firefox today, via the Stylo Rust crate originally developed in the research browser engine Servo. Servo can do parallel layout in some capacity (but doesn't implement everything), https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep... is an interesting and recent document on the matter.
Parallel layout is generally considered to be a complex engineering problem by domain experts.
https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en... is a really cool article that is related, that is a few years old but what it says is largely correct today.
What are some alternatives?
eioio - Effects-based direct-style IO for multicore OCaml
tauri - Build smaller, faster, and more secure desktop applications with a web frontend.
console - a debugger for async rust!
webview - Tiny cross-platform webview library for C/C++. Uses WebKit (GTK/Cocoa) and Edge WebView2 (Windows).
ocaml-multicore - Multicore OCaml
qtwebengine - Qt WebEngine
shuttle - Shuttle is a library for testing concurrent Rust code
xsv - A fast CSV command line toolkit written in Rust.
TLAPLUS_DeadlockEmpire - Specs and models for solving the DeadlockEmpire problems using TLA+ and TLC
xi-editor - A modern editor with a backend written in Rust.
triple-buffer - Implementation of triple buffering in Rust
Fractalide - Reusable Reproducible Composable Software