DEV Community: Lori-Shu

Architectural Decisions: Multi-Process vs. Multi-Threading

Lori-Shu — Wed, 30 Sep 2026 15:47:28 +0000

When designing parallel and concurrent systems, developers invariably face a core architectural dilemma: Multi-Process vs. Multi-Threading.

If you learned systems programming in C, you likely remember fork() and join() (or waitpid()) as the default primitives for spawning and managing execution units. In the early days of Linux, POSIX thread implementations were notoriously fragile, making process cloning the de facto standard for parallelism.

However, as operating systems matured and production-grade threading models stabilized, a massive wave of systems migrated toward multi-threading.

The Case for Multi-Threading

Multi-threaded architectures offer compelling performance and developer-experience advantages:

Seamless Memory Sharing: Sharing state and pointers across threads is fundamentally simpler and cheaper than orchestrating Inter-Process Communication (IPC) mechanisms like shared memory segments, pipes, or Unix domain sockets.
Lower Allocation Overhead: Spawning a thread carries significantly less CPU and memory overhead compared to cloning an entire process address space.
Predictable Lifecycle Management: Thread lifecycles are naturally tied to their parent process. When the host process exits, its threads are cleaned up automatically, reducing the risk of dangling zombie processes or lingering resource leaks.

Why Multi-Process Is Far From Obsolete

Despite the popularity of threads, the multi-process model remains indispensable for specific high-assurance workloads:

Error Isolation & Fault Tolerance: A panic, segmentation fault, or unhandled exception in a worker thread can crash the entire application. In contrast, a crashed process dies in isolation, leaving the primary supervisor running intact—making it ideal for sandboxing and plugin ecosystems (e.g., modern web browsers).
Granular Observability & Debugging: Because each child process operates with a distinct PID, OS-level tools like htop, perf, and strace can monitor resource usage, memory footprints, and system calls per unit much more cleanly than inside a dense multi-threaded runtime.
Language-Specific Workarounds: In languages constrained by a Global Interpreter Lock (GIL)—such as Python or Ruby—multi-processing remains the primary strategy for bypassing single-core bottlenecks to achieve true multi-core utilization.

Summary

Neither pattern is inherently superior; the optimal choice depends on your application's constraints:

Reach for Multi-Threading when performance, shared memory access, and low latency are your top concerns.
Reach for Multi-Processing when safety, crash resilience, and strict fault isolation outweigh the overhead of IPC.

Shrinking Your Rust Allocations: Replacing Vec and String with Boxed Slices

Lori-Shu — Mon, 28 Sep 2026 16:00:43 +0000

When building high-performance systems in Rust, managing dynamic allocations efficiently is key to keeping your memory footprint lean.

Developers often reach for Vec<T> and String by default whenever they need owned collections. However, if data is read-only after creation—such as static assets, loaded images, or unmodifiable configuration strings—holding onto expandable collections wastes unnecessary bytes on the stack.

By "downgrading" fixed-size collections from dynamic types like Vec<T> and String to boxed slices like Box<[T]> and Box<str>, you can trim excess heap metadata without sacrificing ownership.

Why Box<[T]> Beats Vec for Static Data

A Vec<T> and a String carry 24 bytes of stack metadata (on 64-bit systems):

A heap pointer (8 bytes)

The current length (8 bytes)

The allocated capacity (8 bytes)

Because dynamic vectors must support growing and shrinking, they maintain spare capacity. But if your data is loaded once and never resized, tracking capacity is unnecessary overhead.

Converting to a boxed slice (Box<[T]> or Box<str>) drops the capacity field entirely, shrinking stack metadata down to 16 bytes (pointer + length). Across thousands of instances, this metadata reduction adds up quickly.

Practical Implementation

Here is how you can convert dynamic types into boxed slices using .into_boxed_slice() and .into_boxed_str():

use std::path::Path;

pub struct NamedImage {
    buf: Box<[u8]>,
    name: Box<str>,
}

impl NamedImage {
    pub fn new(img_path: &Path, img_name: String) -> Self {
        // Load raw image data and shrink allocation from Vec<u8> to Box<[u8]>
        let buf = image::load_png(img_path).into_boxed_slice();

        // Convert owned String to Box<str>, dropping capacity overhead
        let name = img_name.into_boxed_str();

        Self { buf, name }
    }
}

When .into_boxed_slice() or .into_boxed_str() is called, Rust reallocates or re-slices the heap allocation to match the exact length of the data, freeing any excess capacity back to the allocator.

Beyond &self and &mut self: Rust’s Underrated Method Receivers

Lori-Shu — Sun, 27 Sep 2026 16:51:34 +0000

If you write Rust, you interact with &self and &mut self every single day. They are the backbone of idiomatic Rust, signaling at a glance whether a method reads from or mutates an instance.

However, Rust’s ownership and type system goes deeper than just standard references. Tucked inside the language specification is arbitrary self types—allowing specialized receivers like self: &Arc and self: &Mutex.

While rare in everyday application code, these self-types are power tools when architecting concurrent and multi-threaded systems.

The Standard Receivers: A Quick Refresh

Before diving into the exotic variants, here is how the standard receivers behave:

&self (Shared Reference): Borrow the instance immutably. Multiple callers can execute this method simultaneously without mutating state.

&mut self (Exclusive Reference): Borrow the instance mutably. Guarantees exclusive access to modify the object's internal fields.

self (By Value): Consume the instance, taking full ownership and moving it into the method.

The Power Receivers: &Arc and &Mutex

In concurrent Rust, state is frequently wrapped inside thread-safe smart pointers or synchronization primitives—most notably Arc<T> (Atomic Reference Counting) and Mutex<T>.

Normally, calling a method on an Arc requires cloning the Arc explicitly before calling a standard method:

// Traditional approach
let shared_node = Arc::new(MyNode::new());
MyNode::process_node(shared_node.clone());

By explicit receiver typing, you can make the method itself demand the smart-pointer wrapper directly on self:

impl MyNode {
    // Requires the caller to pass a reference to the Arc wrapping this instance
    pub fn spawn_task(self: &Arc<Self>) {
        let clone = Arc::clone(self);
        tokio::spawn(async move {
            clone.do_work();
        });
    }
}

How do I encapsulate a tool type in Rust?

Lori-Shu — Mon, 31 Aug 2026 14:05:56 +0000

I’ve been wrapping a few tool types in a Rust project lately and ran into some friction. Along the way I picked up a few practical lessons on what a clean tool type should look like. Here’s what I landed on:

Decouple unrelated fields:
The first and hardest step is deciding which fields the type actually owns. Real-world code is full of types that do more than they should; those extra responsibilities are usually candidates for being pulled out.

Prefer immutable interfaces:
A good tool type should expose only immutable methods so callers never need a mutable handle. Rust’s type system pushes you in this direction, and following it let me drop a lot of interior-mutability wrappers I had previously needed at runtime.

Distinguish different kinds of output:
Some values are fixed once the type is created; others change over time. The former can stay as plain owned types, while the latter are better expressed as shared types. I also try to avoid handing out mutable references. When mutation is required, specific methods should own that responsibility.

Insight:
A surprising amount of this is already enforced by the Rust type system. The rules can feel strict, but treating the compiler as a collaborator usually leads to cleaner design and less code.

Introduction to Experiment Indicators

Lori-Shu — Mon, 24 Aug 2026 15:43:57 +0000

Scientific experiments typically need clear indicators to measure and quantify performance. This is especially true in data-processing contexts, where several key metrics deserve close attention.
We can start with a few fundamentals familiar from high-school math: the average (mean), the mode, and the variance. The average corresponds to the "expectation" discussed in probability courses; it summarizes the overall property of a dataset in a single number. The mode is simply the value that appears most frequently. Variance indicates stability—if a dataset shows large variance, it is considered unstable.
Residual is another useful indicator. It measures the difference between data points that have a time-domain character. Residuals are particularly valuable in signal processing, where data are typically ordered by time. They are calculated by taking the difference between values at separate time points.
From residual we derive RSS (Residual Sum of Squares), also known as SSE (Sum of Squared Errors). RSS is obtained by squaring each residual and then summing the results. RMSE (Root Mean Squared Error) takes this a step further: it divides the RSS by the number of data points and then takes the square root. The result has the same magnitude as the original data and effectively represents the average residual. RMSE is especially powerful when the data contain both positive and negative values, because squaring prevents opposing residuals from canceling each other out.

The Trend of Modern Programming Languages

Lori-Shu — Sun, 23 Aug 2026 16:06:05 +0000

In 2026, programming languages—the core tools of software engineers—are undergoing a clear and accelerating shift: they are becoming more static.
Two major design paradigms have long shaped language design. On one side are the static-first languages such as C and Rust. These typically feature strong type systems and sophisticated, heavyweight compilers. On the other side are the dynamic-first languages such as Python and JavaScript. They traditionally rely on weaker type systems while leveraging powerful, professionally engineered runtimes.

Insight:The current trend is unmistakable: languages that once embraced dynamic features are steadily adopting more static characteristics. Many of them have borrowed ideas and mindsets from languages like Rust. Evidence shows that this shift delivers tangible benefits—faster startup times, reduced runtime memory usage, and greater code determinism.
Recognizing this evolution helps us better understand the interplay between static and dynamic elements in our own software. The practical recommendation is straightforward: prefer static approaches whenever possible, and only fall back to dynamic solutions when something is genuinely difficult to make static.

Google's Latest Talent Rearrangement

Lori-Shu — Thu, 06 Aug 2026 15:35:09 +0000

Earlier today, Jeff Dean announced his departure from Google. Who is Jeff Dean? He is one of the most influential figures in Google's history and one of the company's two legendary chief engineers. As a core technical leader, his departure sends a clear signal that Google is undergoing a significant internal talent transition. Since joining Google in 1999, Jeff Dean has contributed to nearly every major product and infrastructure initiative developed by the company. Let's revisit his remarkable journey at Google.
For general users worldwide, Jeff Dean's influence can be seen across many Google products, including Google Search, Gmail, Google Translate, YouTube, Chrome, and Gemini. Some of these products were developed directly under his technical leadership, and they have collectively shaped the digital experiences of billions of users.
For developers and engineers, Jeff Dean is widely regarded as a pioneer of large-scale computing. He played a key role in designing foundational frameworks and systems such as MapReduce, BigTable, GFS (Google File System), Pregel, and TensorFlow. Several of these innovations later inspired influential open-source projects, including Apache Hadoop MapReduce, bringing large-scale computing capabilities to developers around the world.
Insight: Jeff Dean's departure comes amid ongoing speculation about internal disagreements among Google's senior leadership. While Google may be losing one of its legendary technical figures, the broader technology ecosystem continues to benefit from the contributions of pioneers like him. The impact of such talents extends far beyond any single company, ultimately advancing the progress of the entire industry.

The Basic Animation Mechanism in Egui

Lori-Shu — Sat, 11 Jul 2026 14:02:27 +0000

As an immediate-mode UI framework, egui handles animations in a fundamentally different way from traditional retained-mode UI frameworks. Instead of maintaining an explicit animation object, egui provides helper functions such as ui.animate_bool_with_time() -> f32 to track animation progress internally.
The method takes three arguments: an Id (a unique identifier for the animation state), a Boolean flag, and a duration specified as a 32-bit floating-point value. Internally, the egui runtime caches a floating-point state associated with the given Id. This value smoothly transitions from 0.0 to 1.0, or reverses from 1.0 back to 0.0, depending on the state change of the Boolean flag.
During each repaint cycle, egui retrieves the cached animation state using the corresponding Id and updates its progress. The Boolean flag determines the animation direction, while the returned floating-point value represents the current animation progress. Developers can then use this value to control rendering parameters, such as opacity, position, or size.
Insight: Although egui's built-in animation functions are convenient, they are not always sufficient for more sophisticated animation requirements. In such cases, developers should manually manage animation progress using ui.time(). These helper animation functions implicitly maintain internal state, such as a floating-point progress variable, behind the scenes. Understanding this underlying mechanism is essential for designing more advanced animations and for gaining a deeper understanding of egui's immediate-mode paradigm.

The Transition from Code to Standard

Lori-Shu — Wed, 08 Jul 2026 16:09:37 +0000

Some software eventually evolves into an official standard. The word standard itself implies that such software has been recognized as authoritative, reliable, and widely accepted. A good example is the Opus audio codec, which was originally developed by the Xiph.Org Foundation and later standardized as an IETF (Internet Engineering Task Force) RFC. Standardization greatly accelerated the adoption of Opus, allowing it to become one of the most widely used audio codecs on the Internet.
Achieving this transition from code to standard is far from easy. Software intended for standardization must be implemented with exceptional quality, accompanied by clear specifications, and undergo extensive technical review and multiple rounds of discussion and voting before it is accepted by organizations such as the IETF.
Insight. Software that has become part of an official standard provides excellent learning material for developers. It demonstrates not only how to write high-quality code, but also how to design software that is robust, interoperable, and maintainable. As developers, striving to produce work that is eventually worthy of standardization is a meaningful long-term goal.

The Rotation Logic of an AVL Tree

Lori-Shu — Sun, 05 Jul 2026 08:35:20 +0000

Oh, my drawing is in a mess but I hope it makes sense.

Breaking： FFmpeg News

Lori-Shu — Thu, 02 Jul 2026 15:28:49 +0000

FFmpeg announced that their native AAC encoder was rewritten and achieved SOTA with respect to quality. https://x.com/FFmpeg/status/2072320220509741087?s=20

The Direct-Access Array

Lori-Shu — Wed, 01 Jul 2026 15:56:21 +0000

The Direct-Access Array is one of the simplest data structures. It stores data at the index corresponding to the value of the data itself. Typically, the stored type is a boolean flag indicating the existence of this value. Utilizing a Direct-Access Array yields optimized constant time complexity when storing and reading data (by incrementing the index and accessing the memory that the index points to). It also can be used to detect duplicates. When we try storing a number and the boolean flag is true, we find a duplicate. This characteristic can be used to replace the HashSets in the cases that the largest number is known to be bounded within a reasonable range. Aside from the replacement optimization, the special array is used in the "buckets" structure in the highly efficient Radix Sort algorithm.
Insight: Simple data structures often deliver high performance but often cannot implement sophisticated operations. We should consider these simple data structures when facing limited computational resources and pursuing highly efficient algorithms.