libuv | rr | |
---|---|---|
75 | 102 | |
23,358 | 8,684 | |
1.1% | 1.3% | |
9.0 | 9.6 | |
4 days ago | 5 days ago | |
C | C++ | |
MIT License | GNU General Public License v3.0 or later |
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.
libuv
- Epoll: The API that powers the modern internet (2022)
-
APIs in Go with Huma 2.0
I wound up on a different team with pre-existing Python code so temporarily shelved my use of Go for a bit, and we used Sanic (an async Python framework built on top of the excellent uvloop & libuv that also powers Node.js) to build some APIs for live channel management & operations. We hand-wrote our OpenAPI and used it to generate documentation and a CLI, which was an improvement over what was there (or not) before. Other teams used the OpenAPI document to generate SDKs to interact with our service.
- Python Is Easy. Go Is Simple. Simple = Easy
-
Notes: Advanced Node.js Concepts by Stephen Grider
In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.
- A Magia do Event Loop
-
A complete guide to the Node.js event loop
Libuv, the C library that gives Node.js its asynchronous, non-blocking I/O capability is responsible for managing the thread pool. Node.js gives you the capability of using additional threads for computationally expensive and long-lasting operations to avoid blocking the event loop.
-
What is Node.js?: A Complete Guide
Node.js is written in C, C++, and JavaScript. The core components of Node.js - the V8 engine and the libuv library - are written in C++ and C, respectively, since these languages provide low-level access to system resources, making them well-suited for building high-performance and efficient applications. JavaScript is mainly used to write the application logic.
-
Node v20.3.0 (Current) upgrade to libuv 1.45.0, including SIGNIFICANT performance improvements to file system operations on Linux
x8 apparently https://github.com/libuv/libuv/pull/3952
-
Node.js – v20.3.0
Notably upgrades to libuv 1.45 which has io_uring support. Faster file system access! Awhh yeah, it's on.
Remarkable what a mild & unintrusive PR adding io_uring was. https://github.com/libuv/libuv/pull/3952
-
Using Parallel Processing in Node.js and its Limitations
Well, the single-threaded nature ultimately leads to its biggest downfall. Node.js utilizes a synchronous event loop engineered using Libuv that takes in code from the call stack and executes it.
rr
- rr: Lightweight Recording and Deterministic Debugging
-
Hermit is a hermetic and reproducible sandbox for running programs
I think this tool must share a lot techniques and use cases with rr. I wonder how it compares in various aspects.
https://rr-project.org/
rr "sells" as a "reversible debugger", but it obviously needs the determinism for its record and replay to work, and AFAIK it employs similar techniques regarding system call interception and serializing on a single CPU. The reversible debugger aspect is built on periodic snapshotting on top of it and replaying from those snapshots, AFAIK. They package it in a gdb compatible interface.
Hermit also lists record/replay as a motivation, although it doesn't list reversible debugging in general.
- Rr: Lightweight Recording and Deterministic Debugging
-
Deep Bug
Interesting. Perhaps you can inspect the disassembly of the function in question when using Graal and HotSpot. It is likely related to that.
Another debugging technique we use for heisenbugs is to see if `rr` [1] can reproduce it. If it can then that's great as it allows you to go back in time to debug what may have caused the bug. But `rr` is often not great for concurrency bugs since it emulates a single-core machine. Though debugging a VM is generally a nightmare. What we desperately need is a debugger that can debug both the VM and the language running on top of it. Usually it's one or the other.
> In general I’d argue you haven’t fixed a bug unless you understand why it happened and why your fix worked, which makes this frustrating, since every indication is that the bug exists within proprietary code that is out of my reach.
Were you using Oracle GraalVM? GraalVM community edition is open source, so maybe it's worth checking if it is reproducible in that.
[1]: https://github.com/rr-debugger/rr
-
So you think you want to write a deterministic hypervisor?
https://rr-project.org/ had the same problem. They use the retired conditional branch counter instead of instruction counter, and then instruction steeping until at the correct address.
-
Is Something Bugging You?
That'll work great for your Distributed QSort Incorporated startup, where the only product is a sorting algorithm.
Formal software verification is very useful. But what can be usefully formalized is rather limited, and what can be formalized correctly in practice is even more limited. That means you need to restrict your scope to something sane and useful. As a result, in the real world running thousands of tests is practically useful. (Well, it depends on what those tests are; it's easy to write 1000s of tests that either test the same thing, or only test the things that will pass and not the things that would fail.) They are especially useful if running in a mode where the unexpected happens often, as it sounds like this system can do. (It's reminiscent of rr's chaos mode -- https://rr-project.org/ linking to https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo... )
-
When "letting it crash" is not enough
The approach of check-pointing computation such that it is resumable and restartable sounds similar to a time-traveling debugger, like rr or WinDbg:
https://rr-project.org/
https://learn.microsoft.com/windows-hardware/drivers/debugge...
- When I got started I debugged using printf() today I debug with print()
- Rr: Record and Replay Debugger – Reverse Debugger
-
OpenBSD KDE Plasma Desktop
https://github.com/rr-debugger/rr?tab=readme-ov-file#system-...
What are some alternatives?
libevent - Event notification library
CodeLLDB - A native debugger extension for VSCode based on LLDB
Boost.Asio - Asio C++ Library
rrweb - record and replay the web
libev - Full-featured high-performance event loop loosely modelled after libevent
gef - GEF (GDB Enhanced Features) - a modern experience for GDB with advanced debugging capabilities for exploit devs & reverse engineers on Linux
tokio-uring - An io_uring backed runtime for Rust
Module Linker - browse modules by clicking directly on "import" statements on GitHub
uvw - Header-only, event based, tiny and easy to use libuv wrapper in modern C++ - now available as also shared/static library!
nbdev - Create delightful software with Jupyter Notebooks
C++ Actor Framework - An Open Source Implementation of the Actor Model in C++
clog-cli - Generate beautiful changelogs from your Git commit history