Forem: Anton Dolganin

Did you know that a shell is just an ordinary program?

Anton Dolganin — Sat, 16 May 2026 14:11:20 +0000

Many people think that the command line (bash, zsh) where we type our commands is some deeply integrated, magical part of the operating system.

In reality, a shell is just the starting program on your server. When you log in via SSH, the system looks into the user's configuration file and runs whatever is specified there. If you replace /bin/bash with the path to Python, you'll end up in the Python interpreter. If you specify /usr/bin/top, the task manager will open, and exiting it will immediately close your SSH session.

But how does a shell work under the hood? Fundamentally, it's just an infinite loop. Here is what its minimalist skeleton looks like in modern C.

Minimal Shell (based on the UNIX pattern)


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/wait.h>

#define MAXLINE 4096

int main(void) {
    char buf[MAXLINE];

    printf("%% ");

    while (fgets(buf, MAXLINE, stdin) != NULL) {
        size_t len = strlen(buf);
        if (len > 0 && buf[len - 1] == '\n') {
            buf[len - 1] = '\0';
        }

        pid_t pid = fork();

        if (pid < 0) {
            perror("fork error");
            exit(EXIT_FAILURE);
        } else if (pid == 0) { /* child process */
            execlp(buf, buf, (char *)NULL);

            /* if execlp returns control, then an error occurred. */
            fprintf(stderr, "couldn't execute: %s\n", buf);
            exit(127);
        }

        /* parent process */
        int status;
        if (waitpid(pid, &status, 0) < 0) {
            perror("waitpid error");
            exit(EXIT_FAILURE);
        }

        printf("%% ");
    }

    exit(EXIT_SUCCESS);
}

How it works under the hood

The entire essence of a classic UNIX shell boils down to the fork-exec-wait pattern, which can be described in five simple steps:

Read a line of input from the user in a loop.
Strip the newline character left after pressing Enter.
Fork the process — ask the OS kernel to create an exact copy of our program.
If it's the child process, replace ourselves with the program whose path the user entered.
If it's the parent (our original shell), simply wait for the child to finish, and then print the % prompt again.

What is the "magic of fork"?

After calling the fork() function, the operating system clones the process. Both processes continue execution from the exact same line of code (the return from the fork function). They differ in only one way: in the child process, the function returns 0, while the parent receives the ID of the newly created clone. This value acts as a fork in the road, forcing the processes down different branches of the if-else statement.

Important caveat:

This code is intentionally bare-bones and serves purely educational purposes. It doesn't know how to handle parameters (a command like ls -l will throw an error because the system will look for a single executable file with a space in its name), and it doesn't support built-in commands like cd or exit, nor pipes. A real shell does a massive amount of work tokenizing your input string and configuring file descriptors before calling exec. Nevertheless, absolutely every terminal is built on top of this elegant mechanism.

How the CPU Breaks Your Multithreading (False Sharing)

Anton Dolganin — Fri, 08 May 2026 10:23:59 +0000

Imagine a typical scenario: you're optimizing a high-load backend or a network service. It doesn't matter what language you use — C, C++, Java, Go, or C#. You have several threads, and you decide to get rid of slow locks. After all, mutexes are a bottleneck, right?

You apply a classic pattern: instead of threads elbowing each other around a shared variable, you give each thread (or goroutine) its own independent counter. No shared data — no conflicts. You run your load tests expecting beautiful linear scaling, but the profiler shows something weird. The threads seem to still be waiting in line, and the code runs almost slower on a multi-core machine than on a single core.

How is this possible if there are no more locks in the code?

Welcome to the real world, where your programming language's abstractions crash into harsh hardware realities. The problem is that the CPU doesn't care how you logically separated variables in your code. The culprit is False Sharing — an invisible hardware lock.

To understand why your perfect lock-free code is lagging, we need to look under the hood and see how the CPU actually reads memory.

Cache Lines: How the CPU Sees Memory

The CPU never reads memory one byte at a time. It's simply too slow. Instead, it loads data in blocks called cache lines. In modern architectures, a single cache line is usually 64 bytes.

If the CPU needs a 4-byte variable, it grabs it along with the neighboring 60 bytes and puts the whole block into its cache.

Here is a very simplified memory hierarchy by access time:

L1 Cache (per core): the fastest (~1 nanosecond), but small.
L2 Cache (per core): slightly slower (~4 nanoseconds), but larger.
L3 Cache (shared across all cores): slow (~15-20 nanoseconds), but massive.
RAM: the "turtle" (~100 nanoseconds).

The Illusion of Independence

Let's go back to our network packets. We created a C structure holding counters for two cores:


struct PacketCounters {
    int core1_count; // 4 bytes
    int core2_count; // 4 bytes
};

struct PacketCounters counters;

Question: Isn't the structure a single entity? How can one core update part of it while another updates the rest?

The answer lies in the fact that the CPU doesn't care about structures. Structures only exist in the programming language. To the processor, it's just a continuous block of memory. core1_count and core2_count sit right next to each other in memory. Together they take up only 8 bytes, which means they are guaranteed to end up in the exact same 64-byte cache line.

The Ping-Pong Effect, or the "Hardware Mutex"

We thought we got rid of the mutex because Core 1 only writes to core1_count, and Core 2 only writes to core2_count. But here is what happens at the hardware level:

Core 1 increments core1_count. It loads the entire 64-byte line into its L1 cache and changes the value there.
The CPU's cache coherence protocol sees that the data in the line has changed. To prevent desynchronization, it invalidates (marks as garbage) this exact cache line in the caches of all other cores.
Core 2 wants to increment core2_count. It tries to access its L1 cache, but sees that its cache line has been dropped! It is forced to re-fetch it from the slow L3 cache or RAM.
Core 2 changes the value and... invalidates the cache for Core 1.

Even if the cores are working strictly in parallel, this 64-byte memory line bounces between them like a ping-pong ball. An "invisible mutex" is formed at the hardware level.

How to Fix It?

Since the problem is that independent data is sitting too close, the solution is obvious — move them apart.

We need to make sure that each core's counter lives in its own cache line. To do this, we pad the variables (adding empty bytes) to blow up the size to 64 bytes:


#include <stdalign.h>

// Using compiler alignment
struct PaddedCounter {
    alignas(64) int count; 
    // The compiler will automatically add 60 bytes of padding here
};

struct PaddedCounter counters[2]; // Now they are definitely in different cache lines

Because we artificially stretched the size of PaddedCounter to 64 bytes, counters[0] (for Core 1) and counters[1] (for Core 2) will now be placed in completely separate memory blocks. They are guaranteed to sit in different cache lines and will no longer reset each other's caches.

Summary: Lock-free programming is great. But if you forget that the CPU manages memory in 64-byte chunks, you might end up with code that runs slower on a multi-core machine than on a single thread.

💡 A quick footnote: is a cache line always 64 bytes?

In the examples above, we hardcoded 64 bytes — this is the standard for the vast majority of modern processors. But in production code, manually writing magic numbers is a bad practice (what if the code runs on an architecture with a 128-byte cache?). Therefore, in real projects, the size is determined dynamically: for example, C++17 added the cross-platform constant std::hardware_destructive_interference_size, and in Java, developers don't have to think about bytes at all — just adding the @Contended annotation tells the JVM to automatically spread the data across different cache lines.

Rust: Transparent Wrappers with Deref Coercion

Anton Dolganin — Thu, 08 Jan 2026 16:41:00 +0000

The Newtype pattern (struct Username(String)) is great for type safety, but it often feels clunky because you lose direct access to the inner type's methods. Implementing the Deref trait solves this, making your wrapper behave like the data it holds.

Why Use It

Zero-Cost Abstraction: Strict type differentiation (e.g., Username vs. Password) without the boilerplate of proxying every method.
API Ergonomics: Seamlessly use methods like .len(), .is_empty(), or .contains() directly on your custom struct.

Implementation


use std::ops::Deref;

struct Username(String);

impl Deref for Username {
    type Target = str; // The type we want to "mimic"

    fn deref(&self) -> &Self::Target {
        &self.0 // Return a reference to the inner value
    }
}

In Action

Thanks to Deref Coercion, the compiler automatically triggers .deref() when it encounters a type mismatch that can be resolved by a reference.


let name = Username("Anton".to_string());

// 1. Direct access to &str methods
println!("{}", name.len());        
println!("{}", name.contains("a")); 

// 2. Passing to functions expecting &str
fn greet(s: &str) {
    println!("Hello, {s}");
}

greet(&name); // Coercion kicks in here

Intent Matters: Only use this when the wrapper is conceptually a “smart pointer” or a transparent extension. If the inner type’s methods could break your struct’s internal logic, stick to manual method delegation.

Rust CI: Security, Dependency Policy, Coverage Gate, and Fast Builds

Anton Dolganin — Sun, 23 Nov 2025 16:52:38 +0000

A typical GitHub Actions workflow for Rust:

runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Install cargo-audit, cargo-deny, tarpaulin, chef
    run: cargo install cargo-audit cargo-deny cargo-tarpaulin cargo-chef

  - name: Security check
    run: cargo audit

  - name: Dependency policy check
    run: cargo deny check

  - name: Test coverage gate
    run: cargo tarpaulin --fail-under 80

  - name: Build using cargo chef
    run: |
      cargo chef prepare --recipe-path recipe.json
      cargo chef cook --recipe-path recipe.json
      cargo build --release

This pipeline:

performs security validation,
enforces dependency and license policies,
ensures test coverage quality,
and builds your Rust project quickly using dependency caching.

What each step does:

Security check (cargo-audit)

cargo audit

Scans Cargo.lock for vulnerable, deprecated, or compromised dependencies using the RustSec advisory database.

Dependency policy check (cargo-deny)

cargo deny check

Validates your dependency graph: licenses, banned crates, duplicates, and other policy rules.

Test coverage gate (cargo-tarpaulin)

cargo tarpaulin --fail-under 80

Measures test coverage and fails the CI pipeline if coverage is below 80%.

Fast build using cargo-chef


cargo chef prepare --recipe-path recipe.json
cargo chef cook --recipe-path recipe.json
cargo build --release

prepare: generates a dependency recipe.
cook: builds and caches dependencies separately.
cargo build --release: final build using a warmed dependency cache.

via @Let's Get Rusty

Makefiles — add a make help command

Anton Dolganin — Wed, 19 Nov 2025 17:48:57 +0000

If you’re using Makefiles — add a make help command.
It auto-parses comments and shows all tasks instantly.

Simple hack, huge productivity boost.

help:
    @awk 'BEGIN {FS=":"} \
    /^#/ {comment=substr($$0,3)} \
    /^[a-zA-Z0-9_-]+:/ {printf "\033[36m%-20s\033[0m %s\n", $$1, comment}' Makefile

Scraping and Summarizing LinkedIn Jobs with a Chrome Extension + ChatGPT

Anton Dolganin — Tue, 09 Sep 2025 13:06:40 +0000

Intro

Scrolling through endless job descriptions on LinkedIn can be overwhelming.

I wanted a faster way to get the essence of a role — so I built a small Chrome extension.

This extension:

Scrapes job descriptions from LinkedIn (directly from the job page)
Cleans up the text (removes tags, weird spacing, extra line breaks)
Sends it to ChatGPT with a custom prompt
Displays a structured summary right inside the popup

All processing happens locally in the browser, and ChatGPT is called directly via API. No backend, no middlemen.

How It Works

Install the extension locally (Load unpacked in chrome://extensions)
Open any LinkedIn job post
Click the extension icon → job description appears in a popup
Hit Send to ChatGPT → receive a clean, structured summary (role, requirements, stack, seniority)

Why Build It?

I often check LinkedIn job posts but most descriptions are long walls of text.

This extension reduces noise and lets me quickly see if a role is relevant.

It’s also a fun example of how browser scripting + OpenAI API can be combined for productivity.

Setup

Clone repo and load unpacked in Chrome:

git clone https://github.com/anton-ds/linkedin-scraper-ext

Then add your OpenAI API key and prompt in the Options page.

Wrap-up

If you’re curious, the code is open-source:

👉 https://github.com/anton-ds/linkedin-scraper-ext

Would love feedback, ideas, or PRs!

String + Length: A Zero-Overhead Trick in C

Anton Dolganin — Mon, 01 Sep 2025 13:39:46 +0000

📌 Problem

In C you often need to keep a string together with its length. Calling strlen() every time means extra memory scans. We want it compact and efficient.

✅ Solution

A tiny trick with typedef + macro:


typedef struct { const char *p; size_t n; } sv;
#define SV(s) { (s), sizeof(s) - 1 }

struct Messages {
    sv error, version, rep_prefix;
};

static const struct Messages mess = {
    SV("error"),
    SV("version"),
    SV("Server reply: ")
};

After preprocessing it becomes:


static const struct Messages mess = {
    { ("error"),          sizeof("error") - 1 },
    { ("version"),        sizeof("version") - 1 },
    { ("Server reply: "), sizeof("Server reply: ") - 1 }
};

— string and its length, no redundant strlen().

Usage


#include <stdio.h>

int main(void) {
    fwrite(mess.rep_prefix.p, 1, mess.rep_prefix.n, stdout);
    fwrite("OK\n", 1, 3, stdout);
    return 0;
}

Handy in network protocols, logging, binary formats — string + size always at hand, zero overhead.

The “best stack” is a myth

Anton Dolganin — Fri, 11 Jul 2025 21:00:21 +0000

There’s no universal tech stack that fits every project.
When choosing a stack, I always focus on 3 things:

The task — what really needs to be done
The team — who will maintain it tomorrow
The context — budget, deadlines, infrastructure

Sometimes it’s Java + Kafka + Kubernetes.
Sometimes it’s just PHP + MySQL on a basic VPS.

Both can be right, if they solve the problem.

Working on combat logic that’s completely independent of the game code

Anton Dolganin — Fri, 27 Jun 2025 22:30:47 +0000

The idea is to let a designer (aka a human) create combat mechanics through an editor, which are then delivered to the game as JSON. It’s exciting to apply old knowledge to new areas like this.

P.S. Spent a good while wrestling with the grid system. Eventually tracked it down to an issue with child components in the engine.

PostgreSQL: Don't Rush to Index BOOLEAN Columns

Anton Dolganin — Mon, 23 Jun 2025 22:03:28 +0000

It might feel natural to index is_active — but in PostgreSQL, it often does more harm than good.

Why?

BOOLEAN has only three values: true, false, NULL.

If values are evenly distributed (e.g. 50/50), the B-tree index is inefficient. The planner will usually pick a sequential scan instead of using the index.

Index helps when:

One value is rare (e.g. 1% are false)
Queries target only rare values

Better option: use a partial index

CREATE INDEX idx_inactive ON users (id) WHERE is_active = false;

Rust for Kids

Anton Dolganin — Wed, 11 Jun 2025 22:04:41 +0000

This article doesn’t aim to teach you Rust or unveil some hidden feature. It’s more like an experiment — a way to show a kid what Rust looks like on the inside (Rust, not the kid), rather than how to write idiomatic Rust code.

In other words, devs are used to judging a language by how well it fits into their mental model of “how code should be written.” And when it doesn’t? That’s when the frustration kicks in.

Here, I tried flipping the perspective — think “picture book”: how the language lives and breathes, not how we’ve learned to structure it.

⚠️ Disclaimer: This article isn’t about Copy types like i32, f64, bool, char, or &T. We're diving into move types — like String — where values are actually moved around.

Alright, let’s roll.

We’ll start with a core idea in Rust: a value (a memory cell) can only have one owner at a time.
Let’s introduce a bit of “storybook” notation:

let = “let it be”
= = “takes ownership”
mut = “money”, yep, just a money ;)

let

Let’s let a own a House:


let a = String::from("House");

Now let’s let b own that same House. According to the rules, the previous owner has to move out — no exceptions:


let b = a;

At this point:


println!("a = {}", a);

Boom — error.

Why? Because a no longer has the right to do anything with the value (its former House). Ownership was transferred, and Rust enforces that hard.

mut

But wait — there’s more. Just owning a House doesn’t mean you can start remodeling it. Think of it like renting someone else's place — ownership without modification rights.

So this will trigger an error:


b.push_str(" with Pool"); // 🔴 error

If you want to make changes, you have to buy the House with some extra money mut.


let mut c = b;
c.push_str(" with pool");
println!("{}", c); // House with pool

Now c has the keys and the renovation permit.

We can share access to the House — say, by letting a buddy crash for a while. You hand them a copy of the keys using &:


let d = &c;
println!("{}", c);
println!("{}", d);

But there’s a catch. According to the social contract, if guests are inside, no renovations allowed. The following code will throw an error:


let d = &c;
c.push_str(" with sandbox");// can't renovate while guests are over
println!("{}", c);
println!("{}", d);// guest is here

You have to wait until the guests leave:


let d = &c;
println!("{}", d);// guest leaves
c.push_str(" with sandbox");

Still confused? There’s a full “guest etiquette” section at the end of the article.

& mut

Now let’s say your buddy wants to add a hot tub. Since that’s a modification to the House, you ask him to chip in — and in return, you give him the real keys with change privileges: &mut.


let e = &mut c;
e.push_str(" and with hot tub");
println!("{}", e);

Just remember: same rule applies — if someone else is holding the keys, you can’t do any remodeling. In fact, while your buddy is chilling in the hot tub, you can’t even enter the house:


let e = &mut c;
e.push_str(" and with hot tub");
println!("{}", c);
println!("{}", e);// buddy’s in the hot tub

You have to wait for them to finish:


let e = &mut c;
e.push_str(" and with hot tub");
println!("{}", e);// buddy’s done
println!("{}", c);

This only applies when you gave out “paid” access (&mut) — not when you just let someone couch-surf with &.

mut &mut

Now we rent out the House again — to another buddy, this time with full mod rights. But this buddy also has their own extra money — mut.


let mut f = &mut c;
f.push_str(" and with garden");

Things are going well, and we decide to buy a second place: Apartment.


let mut c2 = String::from("Apartment");

Our buddy’s not slacking either — “Let me try out the Apartment too,” he says, waving his mut wallet. So he moves out of the House, into the Apartment, and starts upgrading that too:


f = &mut c2;
f.push_str(" with elevator");

Same core idea: ownership with editing rights = &mut. And declaring let mut f means this buddy isn’t tied to just one location — he can move between places and make changes. Because money mut, yep

After he’s gone, we end up with both properties modified:


println!("c: {}", c);
println!("c2: {}", c2);
//c: House with pool and with sandbox and with hot tub and with garden
//c2: Apartment with elevator

Note: When I say “the buddy left,” I mean it literally — he’s gone, out of scope. Rust tracks that. If a variable is no longer used later in the code, Rust considers it dead — like you called delete on it.

That’s why things can seem weird: while the guest is “around,” you’re blocked from doing stuff, but it’s not always clear they’ve “left.” Rust figures it out by analyzing whether the variable is used again — if not, it’s safe to proceed.

Functions

With a few rare exceptions, the same rules apply to functions too. I won’t overload this post with function examples — maybe next time :)

Logic Separation — One Thread per Role

Anton Dolganin — Sun, 08 Jun 2025 17:22:14 +0000

You write:


std::thread network(serve_clients);
std::thread game(game_loop);
std::thread logger(flush_logs);

Yes, everything still runs in sequence (depending on CPU), but the logic is cleanly separated across threads.

It’s way simpler than stuffing everything into one giant loop with a million ifs.
Even on a single core — this model is easier to read, test, and extend.
And once you upgrade to 4+ cores — performance improves instantly, without changing the architecture.
Bonus: each thread handles its own domain. Easier to reason about, debug, and scale independently