DEV Community: Anish Roy

I Built a Local Bill Scanner So My Friend Stops Typing Invoices Into Google Sheets

Anish Roy — Mon, 05 Oct 2026 06:50:51 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My friend Abhik runs a shop. Every invoice and receipt from other shops used to get typed by hand into a Google Sheet. Date, store, items, tax, total.

Now he drops in photos of the bills and presses Scan. Each bill is read on his laptop, shown next to the original photo, and he fixes anything that's off. Only after he approves does it go to the Sheet.

When I showed it to him, this is what he said:

It's really helpful. What amazes me is that all of this runs at zero cost, completely on my own computer. None of my data goes to the cloud or to some unknown company. Everything stays with me.

Code

github.com/pshycodr/invoice-processing-pipeline

How I Built It

Everything runs through Ollama. GLM-OCR or RapidOCR reads the photo, then gemma3:1b turns the text into JSON.

But a 1B model is bad at picking numbers. It kept reading HSN codes as prices. So plain rules now pick the total, date and store, and the model only handles items, category and payment method.

If OCR fails, the bill is marked handwritten, or no items are found, qwen3-vl:4b reads the image directly. Nothing reaches the Sheet without his approval.

The page lets him pick the OCR engine, pick any Ollama model by name, and add his own categories.

Why Does Open Innovation Matter?

These are his suppliers' invoices, with prices and tax numbers. With open models that data never leaves his computer, and each bill costs nothing.

Same idea as a cache with a slow path. The cheap OCR plus small model handles most bills, the vision model only runs on a miss, and he checks the final answer.

hacktoberfest #ollama #opensource

Process, Threads and Goroutines

Anish Roy — Thu, 19 Feb 2026 06:21:51 +0000

What Is a Process?

A program is an executable file on disk.

When the operating system loads that file into memory and starts execution, it becomes a process.

A process has its own:

Memory Address
Registers
Program Counter
Stack and Heap memory
I/O and system resources

The key property is isolation.

Each process has its own resources, and one process cannot access or interact with another process directly.

Although it is possible to communicate with another process via IPC (Inter-Process Communication) and pipes, they need to be intentionally set up.

Example:

Google Chrome runs each tab in a separate process. If one tab crashes or malfunctions, other tabs keep running. That isolation comes from process boundaries.

Cons:

Heavyweight
Expensive context switching
Higher memory usage

The operating systems must save registers, memory mappings, and kernel data structures also know as PCB(Process Control Blocks) on every context switch between process executions.

What Is a Thread?

A thread is the unit of execution inside a process. Its like a subset of the process that runs inside the process boundaries.

Every process has at least one thread, called the main thread. Many processes run multiple threads.

Threads within the same process has same:

memory address
heap and global variables

However, each thread have their own stack and registers Because threads share memory, communication is fast. No need for inter process communication.

But this introduces risk.

any faulty thread can crash the entire process.

Context switching between threads is faster than between processes because:

No memory context switch
Less kernel level operations

Still, thread switching requires kernel involvement. That overhead adds up in highly concurrent systems.

The Problem With Heavy Threads

OS threads are expensive:

Large stack memory, mostly around 1 MB
Kernel managed
Expensive to create and destroy
A blocking system call will block the entire thread

If you spawn thousands of threads, memory usage explodes.

This is where Go changes the model.

What Is a Goroutine?

A goroutine is a lightweight unit of execution managed by the Go runtime, not the operating system.

You start one by prefixing a function call with the go keyword:

go speak("Hello World")

Thats it.

The main function itself runs as a goroutine.

How Goroutines Work

Go uses an M:N scheduling model:

M goroutines
N OS threads

M is usually much larger than N. Which means the Go runtime scheduler multiplexes many goroutines onto fewer OS threads.

On a logical CPU:

One OS thread runs
One goroutine executes at a time
Many runnable goroutines wait in a local queue

When a goroutine blocks on I/O, the runtime:

Parks the thread
Moves other runnable goroutines from that thread to another thread

and Keeps CPU cores busy. This avoids wasting resources.

Why Goroutines Are Lightweight

Initial stack around 2 KB
Stack grows dynamically
Context switching happens in user space
No full kernel switches for goroutine scheduling

You can run large number of goroutines in a single program with modest memory usage.

Work Stealing Scheduler

Go uses a work stealing scheduler.

If one logical CPU runs out of work:

It steals runnable goroutines from another CPUs queue
This balances load across cores

If no local work exists:

The scheduler checks a global queue

This keeps CPUs busy without manual tuning.

Blocking and System Calls

When a goroutine performs a blocking system call:

The OS blocks the thread
The runtime detaches other goroutines
Another thread takes over execution

Some operations, like network polling, use dedicated threads. This reduces unnecessary thread parking.

The result:

You write code that looks synchronous.

The runtime handles concurrency and scheduling.

Fork Join Model in Go

Go follows the fork join idea.

The parent goroutine spawns child goroutines
Child goroutines run concurrently

After execution each child joins back with the parent using synchronization primitives like WaitGroup or channels

Example:

func speak(msg string) {
    fmt.Println(msg)
}

func main() {
    go speak("Hello World")
    time.Sleep(1 * time.Second)
}

If main exits early, the program terminates before the child goroutine finishes. You must coordinate execution.

Goroutines share can memory and communicate, but in that case They must synchronize access using:

Channels
Mutexes
Atomic operations

Ignoring synchronization can leads to race conditions.

Quick Comparison

Feature	Process	Thread	Goroutine
Memory	Own memory space	Shared memory within process	Managed within process memory
Isolation	Strong isolation	No isolation within process	No isolation within process
Weight	Heavyweight	Lighter than process	Very lightweight
Context Switching	Expensive	Faster than process	Very fast, user-space scheduled
Management	OS managed	Kernel managed	Go runtime managed
Scheduling	OS scheduler	OS scheduler	User-space scheduler (Go runtime)
Blocking	Blocks independently	Can block OS thread	Efficient blocking behavior
Failure Impact	Safe from other process crashes	One bad thread can crash process	One bad goroutine can crash process
Synchronization	IPC required	Shared memory requires sync	Requires proper synchronization

When To Use What

Use processes when the priority is:

Strong isolation
Security boundaries
Crash containment

Use threads when:

You need shared memory
You operate outside Go
You rely on OS level primitives

Use goroutines when:

You build concurrent services in Go
You need high concurrency with low overhead
You want simple concurrency syntax

If you build network services, background workers, or streaming systems in Go, goroutines give you scale without thread explosion.

Final Takeaway

A process isolates.

A thread executes inside a process.

A goroutine executes inside a thread but is managed by the Go runtime.

Isolation decreases as you move down the stack and Efficiency increases.

References

What Actually Happens When You Run a Program

Anish Roy — Wed, 18 Feb 2026 18:03:47 +0000

You type a command and press Enter. A program starts in milliseconds. Your operating system performs a long chain of controlled steps. These steps involve the shell, the kernel, the CPU scheduler, and memory management.

This blog traces that journey from the first keystroke to active execution.

Step 1. From Command to Process Creation

Your shell reads your command and parses the text. The shell runs as a normal user process. After parsing, the shell requests the kernel to start a new program.

The kernel performs few actions:

Allocates a process structure in memory
Assigns a unique PID or process ID
Loads the executable file from disk
Maps code and data into virtual memory
Places the process in a ready queue

The executable file contains machine instructions and metadata. The kernel loader maps these sections into the process address space. The process now exists but waits for CPU time.

Step 2. User Mode and Kernel Mode

Modern CPUs enforce privilege separation between User mode and Kernal mode.

User mode runs application code. Hardware access stays restricted. Your program reads and writes memory only inside its own address space.

Kernel mode holds full privileges. The kernel controls hardware, memory, and devices.

When your program needs system resources, it performs a system call. A system call triggers a controlled switch into kernel mode. The kernel validates the request, performs the operation, and returns control to user mode.

This boundary prevents faulty programs from corrupting the system.

Step 3. fork and exec

Unix style systems use a two step model for launching programs.

The fork operation creates a child process. The child receives a copy of the parent memory space and file descriptors. Both processes continue execution from the same point.

The child then calls exec. Exec replaces the child memory with a new program image. The PID remains unchanged. Only the code and data change.

Your shell follows this pattern:

The shell calls fork
The child process calls exec with your command
The parent shell waits or continues based on job rules

This model keeps process management simple and predictable.

Step 4. Process States and Scheduling

Each process moves through defined states:

New → process gets created
Ready → process waits for CPU time
Running → process executes on a core
Waiting → process pauses for input or output
Terminated → process exits

The scheduler decides which ready process runs next through different CPU scheduling algorithms like FCFS, SJF, SRTF, Round Robin etc.

Most schedulers use priorities and time slices. A time slice limits how long a process runs before a switch.

During a context switch, the kernel:

Saves CPU registers of the current process
Loads registers of the next process
Updates scheduling data

Rapid switching creates the illusion of parallel execution.

Step 5. How the OS Tracks Resources

The kernel tracks every process with a process control block.

This structure stores:

Scheduling information
Memory mappings
Open file tables
Accounting data

Virtual memory gives each process an isolated address space. Page tables map virtual addresses to physical memory. The kernel enforces protection rules through these mappings.

File descriptors connect processes to resources. Each descriptor points to a kernel table entry. This entry refers to files, devices, or pipes. The kernel manages permissions and reference counts.

Live Terminal Experiments

You can observe these concepts with simple commands.

Run this in your terminal:

ps aux

You see a snapshot of active processes. Each line represents a kernel tracked process with CPU and memory usage.

Run this next:

top

This display updates in real time. You can watch processes change states as the scheduler rotates tasks.

Start a long running program in one terminal. Observe it with ps or top in another terminal. Stop the program and watch the entry disappear.

Every program you run triggers process creation, scheduling, and resource tracking in a tight loop. These steps happen constantly in the background and shape how your system behaves.

The next time you press Enter in a terminal, you see more than a command. You see a full process lifecycle running under your control.