Forem: lbvf50mobile

Golang G/M/P Time Scale

lbvf50mobile — Wed, 08 Apr 2026 09:09:43 +0000

If we imagine that 1 millisecond is one “day”, then 1 second becomes about 3 years.

1 s ≈ 3 “years”
1 ms = 1 “day”
2 µs ≈ 1 “minute”
10 ns ≈ 1 “second”

Thus, the RTT over 5000 km (~56 ms) is about 2 “months”.

And G/M/P scheduling (context switching), which takes ~1000 ns, is about 30 “seconds” in this scale.

The Archetypal Go Program: Servers, Goroutines, and Scheduling

lbvf50mobile — Thu, 02 Apr 2026 17:08:55 +0000

This post gives an answer to the question: why Go is optimized for concurrent I/O-intensive systems such as network services.

A programming language is not only syntax, but also a runtime implementation. Runtime is the part of the executing program where data structures and algorithms that support syntactic constructs of the language are implemented. Namely, the implementation of dictionaries (maps), sets, asynchrony, parallelism, and concurrency (which are not the same thing).

Golang is unique, and for the 2010s revolutionary, in its implementation of the Syntax + Runtime combination for an ARCHETYPICAL program design. An archetypical Go program is a server running in a single OS process on multiple OS threads, which handles a flood of HTTP requests while maximizing the utilization of OS threads.

As is known, the execution of a program’s algorithm can be blocked algorithmically (something is waiting for a response), or physically when an OS thread waits for I/O. In Go, both types of blocking are reduced to a minimum through the implementation of a virtual processor layer and lightweight goroutines. In this way, virtual processors are switched between OS threads, and goroutines that are waiting and ready to execute are shuffled, so that the real CPU is practically not idle. And the entire mechanism is described with simple and clear syntax.

Thus, Go is designed for writing programs that, within a single OS process, process the maximum number of requests above the Transport Layer in the most optimal way. The archetypical program design is: a listening goroutine that launches handler goroutines for each connection. Everything else is delegated to the runtime. And the runtime, in turn, manages the execution sequence of goroutines across different virtual processors and different OS threads.

    // Core of the Archetypical Go Application 
    listener, _ := net.Listen("tcp", ":8080")  
    for { 
       conn, _ := listener.Accept() 
       go handle(conn)`  
    }

The Go scheduler model is called G/P/M — Goroutine / Processor Virtual / Machine Thread, or alternatively N:M, where N goroutines are executed on M OS threads. Sometimes it is also called M:N, but I prefer to keep the letter M for OS threads.

The essence in one paragraph from ChatGPT:

Go is designed to simplify the development of concurrent I/O-intensive systems. This is achieved through the built-in goroutine model and a runtime scheduler that distributes their execution across a limited number of OS threads (M:N scheduling). As a result, the developer writes simple synchronous code, while concurrency and task switching are handled by the runtime.

Golang HTTP handlers in Middleware

lbvf50mobile — Sat, 28 Mar 2026 06:30:28 +0000

IT IS A DRAFT CONSIDERATION. May has ERRORS.

UPD: The main inside of this text is that Middleware mechanis in Golang is not write a chain of method that call each other. But! Return one method, that in it's core a wrapped "onion" of one closure calls anoter. If it's correct to say. We return a method, that calls a method, that calls a method, and all these methods are required from arguments of the call, and all are in Closure Scope.

If start to consider OS Server Process as an average UNIX OS Process (using very rough simplification): that Process has STDOUT to Write Respond, and STDIN to Read Request from a client. That's clear STDOUT to Write and STDIN to Read.
Next let's wrap these STDOUT and STDIN in Objects described by Interfaces. STDOUT would be http.Respnose to Write, and STDIN would be http.Requst to read from.
Eventually the handling of the request will be a single method ServerHTTP(w http.Responce, r * http.Request). It is a singe method with just two argument one for write and one for read.

Having one method we able to add wrapping methods f1(w,r){ f2(w,r){ f3(w,r){ ServeHTTP(w,r)}}}}.

Also we could put w and r in closures that not writing methods all the time in one place but share them among each other.
// w and r in the Closure.
f1 := func(handler1){ do1(); handler1();}
f2 := func(handler2){ do2(); handler2();}
f3 := func(){ do3(); ServeHTTP(w,r);}
f1(f2(f3()));
Something like hat in a draft with a simplification.

Something like hat in a draft with a simplification.
Yes, it Has Errors. Need to clarify the way a Handler Called. And the way it Return. But the Idea is Correct.

The main thing is: We just create a new Handler method by chain of calls of Middlware - that wrap, wrap, wrap, wrap initial ServeHTTP by Methods with Clouser. Middleware not a function to call, it is a funtion that crate function for call.
That's it. Thanks God, Jesus Christ! The main issue of understanding is closed.

Mental Models from my Diary

lbvf50mobile — Fri, 06 Mar 2026 13:38:41 +0000

Just over viewing my Diary since September 2025 to March 2026 - I extracted next crucial mental models. These mental models are sharped during hard battles in local communities.

Kernel <= SysCalls => UserSpace;

Kernel(TCP) <= Socket => UserSpace(TLS)

Kernel(OSI[1..4])<=Socket=> UserSpace(OSL[5..7])

In common all these models tell about one concept Interface-Contract, that is implemented and kept for decades in UNIX TCP/IP stack. Where the socket interface is a contract between Kernel internal implementation and UserSpace internal implementation. As It is possible to observe these models [Internal]<=Interface=>[WorkingGround] are very similar, and could be found in different areas of Networks and Web Development.

(HTTP.1/HTTP.2/QUIC)<==[request/response interface]==>(Ruby/PHP/Perl/Python frameworks)

Starting from OS and keeping exploring up to App implementation it is required to do the same thing - define Interface-Contracts that would be stable for a long time.

The Golang

lbvf50mobile — Tue, 03 Mar 2026 07:48:04 +0000

After some thought about Golang and Schedulers, comparing with a Ruby scheme I made a next conclusion:

The purpose of the Golang is to combine HTTP server with Business logic in bounds of one OS Process.

Where as in Ruby, Python, PHP - HTTP server is a separate Process that requires expensive IPC.

Golang model changes focus from the Process to Threads - because Threads are execution pathes, Process are more metadata structures that comprises shared data environment among several Threads. And Golang invents ultra light Threads called Goroutines - that allows to reduce cost of injecting new extcution path into the game.

The key part of Golang is Scheduler that take a time-sharing burden of the programmer's shoulders. Now it is easy to write IO-bond programs, because Go Scheluer will manage all these suspended Goroutines automatically.

Go solves a problem that rouse in 1960-1970 in the Mainframes: Optimal usage of CPU during IO-bound tasks, when a program just waits for an user input. Now it is the same condition - program just waits a response from the network.

P.S. It is an overview of a language roots, back in 2009 Golang has it's architecture for that purpose, those times it was a common solution to separate HTTP server from the framework by a socket- or something like that. Today there are a plenty technologies to run all components in one process.

For me it is an explanation of the Standard library model in the Golang.

Eventually I feel the true Essence of Go

lbvf50mobile — Sun, 25 Jan 2026 22:59:43 +0000

The core Idea - Go Scheduler is a Key to an entire Go structure: std lib and an app architecture.

Long story short: I get into G/P/M model of the Go Scheduler, and found the back-bone model of the all Go programs: Separate Goroutine for each TCP connection. One Listening Goroutine with a "listening Socket", and bunch of others serving "connections Socket". Look at that model from the OS perspective and LRQ for P. Got aha moment of AUTO full-filling all CPU-cores with a Job and wrote the next post:

Eventually I feel the true Essence of Go

From the Scheduler mechanics I pick up the real essence of the TOOL - a server with multiple connections and automatic usage of all hardware-threads of a CPU cores. Only through the Scheduler I understood why the Go is really necessary. Go is a tool like an Axe, and I find what and how to chop wood by this axe. Go is a tool for creating a one executable file that starts well optimized server, and each connection to that server is handled by a light-weight UserSpace Thread.

The Idea of Go itself - to write a server that going to handle multiple TCP connections and automate the process of selecting next goroutine to be executed, and leaving for a while goroutines that stalled in waiting of Network response or any other kind of IPC activity. Here is a Root - to create a server where goroutine would handle a connection, and when to execute that goroutine the Go Runtime would decide, Scheduler if be precise.

This Idea become natural and could be literally touchable only after getting into the G/P/M model - where a Logical Processor P is an abstraction level between UserSpace Thread (a goroutine G) and OS Thread (M). Because each OS Thread M is halted/stopped when it waits for SystemCall to response, mean while P with it own G-swarm keep on "billowing". Thus Go - is a "swarm" or "club" of goroutings that pushed into CPU-cores by the Go Scheduler using P as middle slab abstraction of Logical Processor.

All essence of this model, all value of Go as a language is covered inside the Scheduler that allows bot NOT SO AWARE about how to handle new TCP connection cheap. As the algorithm minimize amount of expensive M (OS threads), substituting them by cheap G (Goroutines).

Go is not a modern C - how it use to be explained, Go is not a "Python". First of all Go is a cheap Goroutiens that are fit perfectly for serving HTTP requests. The aim of the Go is to reduce cost of a Concurrency Component on different platforms.

Uh... it was Tough! Love you mates. I love Go and William Kennedy and Kavya Joshi

Concurrency is a pattern, not execution.

lbvf50mobile — Sun, 14 Sep 2025 04:49:18 +0000

Concurrency is a pattern, not execution.

I just read Jonathan Sande's book about Dart. And found there an explanation of concurrency as a running code on one core, when parallelism execution on multiple cores. It is a "half-true" that may be useful for super-beginners who have Dart their first ever language, and have no CS background at all.

But concurrency is a pattern you separate your pieces of code to be able run them independently.

Here is a quote from Jonathan Bodner's "Learning Go" book:

Concurrency is the computer science term for breaking up a single process into independent components and specifying how these components safely share data.

I find it brilliant.

Should You Learn Perl in 2025?

lbvf50mobile — Fri, 05 Sep 2025 06:38:49 +0000

Perl in 2025 🐪

In 2025, I unexpectedly find myself enjoying Perl again — after years of Ruby and Go.

It sounds strange, but Perl hasn’t aged the way many people think. It’s not trendy, elegant, or fashionable — and yet, for certain kinds of work, it feels perfect.

Don’t Learn Perl. Learn UNIX.

Should you learn Perl in 2025?

Honestly — no. At least, not directly.

Start with UNIX system programming:

Work in the shell.
Understand file descriptors and streams.
Learn how processes are born, end, and communicate.
Get comfortable with Bash and other UNIX tools.

Once you understand these things, Perl becomes automatic.

You don’t “study” Perl — you realize you already understand it.

Perl Looks Messy — Until You See the Process

Here’s the key insight:

If you look at Perl from a syntax perspective, it looks messy.

But if you look at it through the lens of UNIX processes and streams, it suddenly becomes crystal clear and intuitive.

Perl isn’t designed like Python or Go, where you build large structures full of imports, frameworks, and abstractions.

A Perl script is simply a process:

born by the OS,
with three streams (STDIN, STDOUT, STDERR),
communicating with other processes,
manipulating files, signals, and descriptors.

When you see programs this way, Perl’s “cryptic” operators and shortcuts stop looking weird — they become beautifully compressed UNIX primitives.

Perl Is a Tool, Not a System

Modern languages — Python, Ruby, Go — often push you toward designing systems.

Perl isn’t like that.

Perl is a sharp tool for solving tasks quickly:

Renaming hundreds of files? One-liner.
Parsing gigabytes of logs? Two-liner.
Automating a messy workflow? Done before lunch.

You don’t worry about architecture, imports, or frameworks.

You just write the code, run the process, and move on.

Perl feels less like a language and more like an extension of your UNIX shell.

Why Perl Lost Popularity

Perl didn’t die — it simply stepped aside. The web changed.

In the early days, the web was simple: HTML pages, images, and tables.

Perl thrived because it could glue things together effortlessly.

But today’s web apps are massive, layered systems with complex UIs, APIs, and distributed backends.

Perl was never designed for this — so it faded from the spotlight.

Why Perl Will Never Fade Away

Perl still matters because it’s tied to UNIX itself.

Its syntax mirrors UNIX primitives directly.
It doesn’t hide processes and streams behind abstractions.
It becomes intuitive only after you understand the OS.

For sysadmins, DevOps engineers, and anyone who works close to the system, Perl remains reliable, concise, and insanely useful.

Perl doesn’t chase trends.

It doesn’t ship breaking changes every six months.

It’s like a ballpoint pen and a squared notebook: simple, stable, always ready when you need it.

Final Thought

Perl developers don’t see programs as abstract algorithms or piles of imports.

They see them as processes — living entities with streams, signals, and descriptors, talking to other processes in a UNIX world.

When you shift to this perspective, Perl syntax suddenly becomes obvious.

It’s not cryptic anymore — it’s just UNIX in shorthand.

Perl isn’t a language you learn.

It’s a language you grow into.

And once you do, it feels like home. 🐪