DEV Community: MinBapE

Docker and Kubernetes

MinBapE — Mon, 05 Jan 2026 13:35:30 +0000

Introduction

Last year, I participated in an external activity with the theme "Development of Container Monitoring Visualization Dashboard in Docker and Kubernetes Environment." To preserve the fundamental concepts of Docker and Kubernetes that I learned at that time, I'm writing this article in the way I understood them.

What is Docker?

When you run nginx on a server or execute a .sh script, from the operating system's perspective, it's just running a process. Docker is similar - running a container ultimately means executing some process. The difference isn't in how the process runs, but in the environment the process perceives. In Docker, processes operate within an isolated environment (filesystem, network, process list, etc.).

1) Why was it adopted?
The biggest advantage of Docker is that it reduces problems arising from different execution environments across servers. Even programs that build well locally often fail to run when moved to a server due to library dependency conflicts or version differences. With Docker, you can bundle applications with their required dependencies for deployment, significantly reducing trial and error from these environmental differences.

2) Definition
To properly explain Docker, it's a platform that allows you to package and run applications in units called Containers. Containers share the operating system kernel while separating the filesystem, network, and process space to run processes in an isolated environment.
Below are key terms for understanding Docker:

Image: An execution template containing files/dependencies/configurations needed for execution = Package

Container: An actually running instance based on an image = Process

Registry: A repository for storing or distributing images (e.g., Docker Hub, Amazon ECR, Google Container Registry, etc.)

In summary, Docker is a tool that creates identical execution environments as images, allowing you to run containers the same way anywhere.

3) Differences from Virtual Machines
Both VMs and Docker provide isolated execution environments, but they differ in their isolation method and weight.
Unlike Containers, VMs virtualize the entire operating system including the guest OS on top of a hypervisor. It's a structure that puts an entire OS on top of the application. This difference typically results in the following characteristics:

Resource Usage: VMs are relatively heavy as they include the OS, while Containers are lightweight.

Startup Speed: VMs require a boot process, but Containers execute closer to process execution, running much faster.

Isolation Level: VMs have stronger isolation as they're separated at the OS level, while Containers have thinner isolation boundaries compared to VMs as they share the kernel.

In summary, VMs are like virtual computers including the OS, while Containers are closer to isolated process execution that shares the kernel.
When you need a different OS environment, VMs are advantageous, and when you want to deploy programs quickly and consistently on the same kernel basis, Containers are beneficial.

What is Kubernetes?

If Docker provides the unit for creating and running Containers, Kubernetes (abbreviated as k8s) is a system for managing those Containers from an operational perspective. Its purpose is to automate problems that arise when services grow and Containers multiply (deployment, failures, scaling, networking, etc.).

1) The Inconvenience of Docker Operations
With Docker alone, running and stopping Containers isn't difficult. However, as services grow and the number of Containers increases, operational aspects become cumbersome. For example, it's not easy to consistently manage tasks like automatically recovering when a Container terminates abnormally (self-healing), scaling to multiple instances in response to traffic increases, and replacing without downtime during deployment using only Docker commands. Eventually, these operational tasks are managed by scripts or people directly, and as scale grows, management complexity rapidly increases.

2) Kubernetes Core Concepts
Kubernetes operates around several core objects:

Pod

The minimum unit for running Containers in Kubernetes

Usually manages one Container or bundles several closely related Containers together.

Deployment

An object that maintains Pods at the desired count and manages version updates (rolling update method that replaces with new versions without shutting down the service)

Service

An object that provides a fixed access point because Pods can have their IPs changed when replaced or restarted

Also serves as internal load balancing.

Node

The physical server or virtual machine where Pods actually run

Multiple nodes together form a Cluster (a unit that bundles and operates multiple servers as one).

Control Plane

The management area that stores the Cluster's state and decides which Pods to place on which Nodes

The core of Kubernetes isn't directly manipulating Containers, but managing to maintain the desired state once you declare it. If you define goals like 'n Pods should be running' or 'this Service should always be accessible', Kubernetes adjusts accordingly.

Summary

Docker is a tool that packages applications and execution environments as Images and allows you to run Containers based on them in a consistent manner.

Kubernetes is a Container orchestration system designed to automate operational issues like deployment/recovery/scaling/networking when multiple Containers come together to form a service.

Using Docker + Kubernetes together, you can create consistent execution environments with Docker and operate those environments stably and efficiently with Kubernetes. Developers only need to prepare code and images, and Kubernetes automates the rest of the operational burden. This combination has become the standard for modern cloud-native application development and operations.

const and constexpr

MinBapE — Mon, 24 Nov 2025 15:08:57 +0000

Introduction

While working on a personal project, I learned about constexpr. I understood the difference between const and constexpr. However, I wondered why constexpr is necessary when const seems sufficient. I want to share what I found in this article.

const

A keyword that promises the compiler that a value cannot be changed.
Once initialized, the value cannot be modified.

const int MAX_USERS = 100;
MAX_USERS = 200;  // Compilation error!

Characteristics

The initialization value can be known at compile time or at runtime.

int A;
std::cin >> A;
const int B = A;  // Valid
// Constant B is determined at runtime, but cannot be changed afterwards.
// The value doesn't need to be known at compile time, but once set, it cannot be changed.

It becomes more powerful when used with references and pointers.

const int* ptr1;        // Cannot change the pointed value
int* const ptr2;        // Cannot change the pointer itself
const int* const ptr3;  // Cannot change both

When const is added to a class member function, the function promises not to change the object's state.

class User {
private:
    std::string name;
    int age;
public:
    // Does not modify member variables
    std::string getName() const {
        return name;
        // age = 30;  // Error occurs
    }

    void setAge(int newAge) {
        age = newAge; // Valid
    }
};

Limitations

If a member variable is declared as mutable, it can be modified even in const member functions.
const can be forcibly removed using const_cast.

constexpr

constexpr is short for "constant expression".
Unlike const, it is a keyword that guarantees the compiler that the value is determined at compile time.
It was first introduced in C++11, and most restrictions have been lifted through version updates.

constexpr int func(int n) {
    return n * n;
}
constexpr int A = 1;        // Initialized to 1 at compile time
constexpr int B = func(2);  // Calculated to 4 at compile time
constexpr int C = func(B);  // Calculated to 16 at compile time

The critical difference from const is as follows:

int func() { 
    int value;
    std::cin >> value;
    return value;
}
const int a = func();      // Valid -> because it's determined at runtime
constexpr int b = func();  // Error occurs

Reasons to Use

Performance is improved as complex calculations can be completed at compile time through compile-time computation.
In C++, array sizes and template arguments must be compile-time constants.
Incorrect calculations can be caught before execution.
The compiler can perform more verification.

// 1. Performance improvement
constexpr int factorial(int n) {
    return (n <= 1) ? 1 : n * factorial(n - 1);
}
constexpr int result = factorial(10);  // Zero calculation cost at runtime

// 2. Array size
constexpr int SIZE = 100;
int buffer[SIZE];  // OK

const int size = getSize();
int arr[size];  // Error in most cases

// 3. Compile-time verification
constexpr int divide(int a, int b) {
    return b == 0 ? throw "error" : a / b;
}
constexpr int x = divide(10, 0);  // Compilation error occurs

When to Use const vs constexpr?

When to use const

Use when the value can be known at runtime, such as user input, configuration values read from files.
Use const to express the intention not to modify arguments passed to a function.
Member functions that do not change the object's state should be declared as const.

When to use constexpr

C++ array sizes must be compile-time constants.
Template parameters must be determined at compile time.
Use when you want to pre-calculate complex computations.
Use in switch statement case labels, static_assert, etc.

Situation	const	constexpr
User input value	O	X
Array size	△	O
Template argument	X	O
Function parameter	O	X
Compile-time calculation	△	O

Summary

const is a promise of immutability, and constexpr is a guarantee of compile-time calculation.
const can accept runtime values, but constexpr is determined only at compile time.

TCP Variable-Length Packet Handling

MinBapE — Sat, 22 Nov 2025 13:41:43 +0000

Introduction

While developing a Socket Chatting program, I encountered a question: how should I handle messages that exceed the predefined buffer size?
This article documents my solution to this problem.

Packet Boundary Problem

// Client
send(sock, packet1, 10, 0);  // Send 10 bytes
send(sock, packet2, 20, 0);  // Send 20 bytes

// Server
char buffer[1024];
int bytes = recv(sock, buffer, 1024, 0);

What will the value of bytes be? 10? 20?
The answer is: "We can't know."

The size of data received from the client is unpredictable.
recv() can:

Receive all 30 bytes at once
Receive 10 bytes and 20 bytes separately
Split into 15 bytes twice
Even split into 7 bytes, 13 bytes, and 10 bytes

This is called the Packet Boundary Problem.

TCP is a Stream Protocol

Unlike UDP, TCP transmits data in byte units rather than message units.

send(sock, "Hello", 5, 0);
send(sock, "World", 5, 0);

When a client sends a 5-byte string twice as shown above, we might think the server will receive it twice as well. However, TCP can merge them into a single stream, resulting in receiving a 10-byte string all at once.

This happens due to the following reasons:

1. Nagle's Algorithm

A mechanism to improve TCP/IP network efficiency by reducing the number of packets to be transmitted.
Small data is buffered and sent together to prevent inefficiency where headers (40 bytes) are larger than data (1 byte).
Operating systems use this because Congestion Control across the entire network takes priority over individual program speed.
While you can reduce latency by disabling Nagle with TCP_NODELAY, this doesn't change TCP's fundamental stream-based nature, so packet boundary handling on the receiving side remains essential.

  setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

2. Network Layer

MTU (Maximum Transmission Unit): Network transmission size is typically limited to 1500 bytes.
Large data is split into multiple IP packets for transmission. Depending on network conditions, packets may not arrive in order or may be lost, but the TCP protocol reassembles them to guarantee order.
- However, during this reassembly process, data may accumulate or be split in the buffer, making data boundaries ambiguous at recv time.

3. `recv()` Call Timing

recv() returns as much data as is currently available, from a minimum of 1 byte to the maximum requested size.
The amount of data received varies depending on when recv() is called.

Solution

Header + Payload Structure

I solved this by including size information in the header.

#pragma pack(push, 1)  // Remove structure padding

struct PacketHeader
{
    PacketType type;   // 2 bytes - Packet type
    uint16_t size;     // 2 bytes - Payload size
};

struct Packet
{
    PacketHeader header;                 // 4 bytes (fixed)
    char payload[MAX_PAYLOAD_SIZE];      // Variable (actual data)
};

#pragma pack(pop)

Both server and client can first read the header to determine the payload size. The packet is wrapped with #pragma pack(push, 1) to process it once the payload is completely accumulated to that size.

Sending

void send_packet(int sockfd, const Packet& packet)
{
    // Convert to network byte order
    Packet send_packet = packet;
    send_packet.header.type = htons(packet.header.type);
    send_packet.header.size = htons(packet.header.size);

    /*
        htons() = Host TO Network Short (2-byte conversion)
        - Converts to network format regardless of current system
          -> Solves the problem of different byte ordering across CPUs
    */

    // Cast data for transmission
    const char* data = reinterpret_cast<const char*>(&send_packet);
    size_t total_size = sizeof(PacketHeader) + packet.header.size;
    size_t sent = 0;

    // Loop until all data is sent
    while (sent < total_size)
    {
        ssize_t n = send(sockfd, 
                        data + sent, 
                        total_size - sent, 
                        0);

        if (n < 0)
        {
            if (errno == EAGAIN || errno == EWOULDBLOCK)
                continue;  // Temporary error, retry

            perror("send failed");
            return;
        }

        // Add sent size
        sent += n;
    }
}

Receiving

We need to create an accumulation buffer.

struct ClientInfo {
    int fd;
    std::vector<char> recv_buffer;  // Accumulation buffer
};

This is necessary because when packets are split during transmission, they must be stored sequentially in this buffer.

bool receive_data(int sockfd)
{
    ClientInfo& client = clients[sockfd];

    char temp[4096];
    ssize_t n = recv(sockfd, temp, sizeof(temp), 0);

    if (n <= 0)
        return false;  // Connection closed or error

    // Accumulate into existing buffer
    client.recv_buffer.insert(
        client.recv_buffer.end(),
        temp,
        temp + n
    );

    return true;
}

void parse_packets(int sockfd)
{
    ClientInfo& client = clients[sockfd];

    // Continue processing while complete packets exist
    while (client.recv_buffer.size() >= sizeof(PacketHeader))
    {
        // Read header first
        PacketHeader* header =
            reinterpret_cast<PacketHeader*>(client.recv_buffer.data());

        uint16_t payload_size = ntohs(header->size);
        size_t packet_size = sizeof(PacketHeader) + payload_size;

        // Check if complete packet has arrived; if not, wait for next recv()
        if (client.recv_buffer.size() < packet_size)
            break;

        // Extract complete packet
        Packet packet;
        memcpy(&packet, client.recv_buffer.data(), packet_size);

        // Endian conversion (network → host)
        packet.header.type = ntohs(packet.header.type);
        packet.header.size = payload_size;

        // Process packet
        handle_packet(sockfd, packet);

        // Remove processed packet
        client.recv_buffer.erase(
            client.recv_buffer.begin(),
            client.recv_buffer.begin() + packet_size
        );
    }
}

Source Code

Socket Chatting Program

Mutex and Lock Guard in C++

MinBapE — Thu, 20 Nov 2025 01:53:59 +0000

Mutex (Mutual Exclusion)

Mutex is a synchronization object that controls access to shared resources in a multithreaded environment.
It is used to prevent Race Conditions that can occur when multiple threads access the same resource simultaneously.

Code Example

#include <mutex>
#include <thread>

std::mutex mtx;
int counter = 0;

void increment() {
    for (int i = 0; i < 100000; ++i) {
        mtx.lock();
        counter++; // Critical Section
        mtx.unlock();
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Counter: " << counter << std::endl;
    return 0;
}

Key Methods

lock()
- Locks the mutex in a blocking manner.
- If another thread has already acquired the lock, it waits until it is released.
unlock()
- Releases the acquired lock.
- Calling this from a thread that hasn't acquired the lock results in undefined behavior.
try_lock()
- Attempts to lock in a non-blocking manner, returning true on success and false immediately on failure.
- Allows performing other tasks without waiting to acquire the lock.

As shown in the example code above, the code region between lock() and unlock() (Critical Section) can only be executed by one thread at a time.
However, if an exception occurs or an early return happens before calling unlock(), a deadlock will occur.

Mutex for Special Situations

recursive_mutex
- A mutex that allows the same thread to acquire the lock multiple times.
- Must call unlock() as many times as the lock was acquired to fully release it.
timed_mutex
- A mutex that allows specifying a timeout.
- Provides try_lock_for() and try_lock_until() methods.

std::timed_mutex tmtx;

void function() {
    if (tmtx.try_lock_for(std::chrono::seconds(1))) {
        // Successfully acquired lock within 1 second
        // Critical Section
        tmtx.unlock();
    } else {
        // Timeout occurred
    }
}

shared_mutex
- Implements a Reader-Writer Lock.
- Supported from C++17.
- Multiple threads can perform read operations simultaneously, but write operations are performed exclusively.

Lock Guard

Manually managing lock() and unlock() is dangerous. The solution to this problem is the RAII (Resource Acquisition Is Initialization) pattern. It acquires resources in the constructor and releases them in the destructor, utilizing C++'s stack unwinding mechanism to ensure resources are safely released even when exceptions occur.

lock guard is one of the classes provided by the C++ standard library that helps reduce mistakes in mutex management.
When using lock guard, the mutex is automatically locked, and when the scope is exited, the lock_guard's destructor is called to automatically release the mutex.

lock_guard

The most basic RAII-based mutex wrapper.
Automatically calls lock() on construction and unlock() on destruction.
The simplest with minimal overhead.
Acquires the lock immediately upon creation.
Cannot control when the lock is released.
Cannot be copied or moved.

#include <mutex>
#include <thread>

std::mutex mtx;
int counter = 0;

void increment() {
    for (int i = 0; i < 100000; ++i) {
        std::lock_guard<std::mutex> lock(mtx);  // Lock on creation
        counter++;
        // Automatically unlocks when leaving scope
    }
}

void safe_function() {
    std::lock_guard<std::mutex> lock(mtx);
    if (some_condition)
        return;
    process_data();  // Unlock guaranteed even if exception occurs
}

unique_lock

Provides various features including deferred locking, condition variable integration, and ownership transfer.
Can manually call lock()/unlock().
Essential for use with condition variables like condition_variable.
Movable but not copyable.

std::mutex mtx;

void flexible_function() {
    std::unique_lock<std::mutex> lock(mtx, std::defer_lock);  // Deferred locking
    prepare_data();
    lock.lock();  // Manually lock at the needed point
    modify_shared_data();
    lock.unlock();  // Can manually release
    cleanup(); // Other tasks without lock

    // Automatically unlocks if still locked when scope ends
}

// Use with condition variables (most common case)
#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;
bool ready = false;

void wait_for_signal() {
    std::unique_lock<std::mutex> lock(mtx);
    cv.wait(lock, [] { return ready; });  // unique_lock required
    process_data();
}

scoped_lock

Supported from C++17.
Used to prevent deadlocks when locking multiple mutexes simultaneously.
Uses the std::lock() algorithm internally.
Identical to lock_guard for a single mutex.

std::mutex mtx1, mtx2;

// Code that can cause deadlock
void thread1() {
    std::lock_guard<std::mutex> lock1(mtx1);
    std::lock_guard<std::mutex> lock2(mtx2);  // Order issue
    // ...
}

void thread2() {
    std::lock_guard<std::mutex> lock2(mtx2);
    std::lock_guard<std::mutex> lock1(mtx1);  // Opposite order!
    // ...
}

// Prevent deadlock with scoped_lock
void safe_thread1() {
    std::scoped_lock lock(mtx1, mtx2);  // Uses deadlock avoidance algorithm
    // ...
}

void safe_thread2() {
    std::scoped_lock lock(mtx2, mtx1);  // Safe regardless of order
    // ...
}

Lock Guard is a method for safely managing mutexes using the RAII pattern.
Since locks are automatically released even in exception or early return situations, it is much safer than manually managing lock()/unlock().

In most cases, lock_guard is sufficient, and unique_lock or scoped_lock should only be used in special situations.
Proper use of these can prevent many bugs that can occur in multithreaded programming.

Smart Pointers

MinBapE — Fri, 14 Nov 2025 18:15:40 +0000

Memory Management in C/C++

Unlike languages such as Java that automatically manage memory through a Garbage Collector, C/C++ requires developers to manually allocate and deallocate memory. This means special attention must be paid to memory management. For example, C uses malloc and free to acquire and release memory, while C++ uses new and delete for the same purpose. While this characteristic allows for greater program efficiency, it also introduces risks such as memory leaks and incorrect deallocation. As a result, C/C++ programmers must always be mindful of memory usage, which is one of the key characteristics of these languages.

// 1. Memory Leak
void memoryLeakExample() {
    int* ptr = new int(42);
    // No delete -> Memory leak
}

// 2. Null Pointer Issue
void nullPointerExample() {
    int* ptr = nullptr;
    *ptr = 10;  // Crash!
}

// 3. Dangling Pointer Issue
void danglingPointerExample() {
    int* ptr = new int(42);
    delete ptr;
    *ptr = 10;  // Accessing already freed memory
}

Smart Pointer

Template classes provided in C++ for safe dynamic memory management

Smart pointers wrap raw pointers and automatically manage memory according to the RAII (Resource Acquisition Is Initialization) principle. Memory is allocated when a Smart Pointer object is created, and automatically deallocated when the destructor is called as it goes out of scope. This prevents memory leaks without developers explicitly calling delete.

Types

Unique Ptr
- Has exclusive ownership.
- Cannot be copied, only move operations are allowed.
- Has almost no overhead and performs nearly identical to raw pointers.

  void uniquePtrExample() {
      std::unique_ptr<int> ptr1 = std::make_unique<int>(42);
      // std::unique_ptr<int> ptr2 = ptr1;  // Compilation error
      std::unique_ptr<int> ptr2 = std::move(ptr1);  // Only move allowed
  }

Shared Ptr
- Multiple objects can share a single resource.
- Internally tracks the number of owners through Reference Counting.
- Memory is deallocated when the last shared_ptr is destroyed.
- Has slight performance overhead due to Reference Counting management.
- Circular references with Shared Ptr can cause memory leaks, in which case Weak Ptr should be used.

  void sharedPtrExample() {
      std::shared_ptr<int> ptr1 = std::make_shared<int>(42);
      std::shared_ptr<int> ptr2 = ptr1;  // Copy allowed
      std::cout << ptr1.use_count();  // 2
  }

Weak Ptr
- Used together with Shared Ptr, it's a pointer that only references objects without ownership.
- Does not increment Reference Counting.
- Used to resolve circular reference issues between Shared Ptr.
- lock() returns a Shared Ptr if the object is still alive, or nullptr if already destroyed.

  void weakPtrExample() {
      std::shared_ptr<int> shared = std::make_shared<int>(42);
      std::weak_ptr<int> weak = shared;  // No reference count increment

      if (auto ptr = weak.lock()) {  // Convert to shared_ptr
          std::cout << *ptr;
      }
  }

Conclusion

Smart pointers are essential tools for modern C++ programming. They help prevent common memory management issues while maintaining the performance characteristics that make C++ powerful. By understanding and using unique_ptr, shared_ptr, and weak_ptr appropriately, you can write safer and more maintainable code.

I/O Multiplexing

MinBapE — Fri, 14 Nov 2025 06:33:34 +0000

Blocking I/O

Blocking I/O is a method where the program stops and waits until an I/O operation completes.

char buffer[1024];
int n = read(socket_fd, buffer, 1024);  // Blocks here
printf("Data received: %s\n", buffer);   // Won't execute until data arrives

When the read function is called, the program waits until data arrives. This means if no data comes, it just keeps waiting indefinitely. In a single-threaded environment, if one socket is blocked, other sockets cannot be processed.

Problems with Thread per Connection

The approach of allocating one thread per client is intuitive and simple to implement, but it has several critical issues in production environments.

void handleClient(int client_fd) {
    while (true) {
        char buffer[1024];
        int n = read(client_fd, buffer, 1024);  // Blocking
        if (n > 0) {
            process(buffer);
            write(client_fd, response, size);
        }
    }
}

while (true) {
    int client_fd = accept(server_fd, ...);
    std::thread(handleClient, client_fd).detach();
}

Issues

Thread Resource Waste
- Each thread spends most of its time in an I/O waiting state (Blocking).
- Actual data processing time is often less than 1% of the entire lifecycle.
Context Switching Overhead
- As the number of threads increases, context switching frequency grows exponentially.
- Costs incurred during context switching:
- Saving/restoring register state
- Cache invalidation (increased cache misses)
- TLB (Translation Lookaside Buffer) flush
- A significant portion of CPU time is consumed by switching rather than actual work.
Memory Exhaustion
- Each thread requires independent stack memory.
- In large-scale services, memory shortage can lead to system instability.
Thread Creation/Deletion Cost
- OS-level overhead during thread creation:
- Kernel resource allocation
- Stack memory allocation and initialization
- TLS (Thread Local Storage) setup
- Scheduler registration
- Accumulated costs become significant in environments with frequent connections.
Scalability Limits
- C10K Problem: Difficulty handling more than 10,000 simultaneous connections

I/O Multiplexing

I/O Multiplexing is a technique where a single process manages multiple file descriptors simultaneously. The program monitors file descriptors to determine what type of I/O events (read, write, exceptions, etc.) have occurred and whether each file descriptor is in a ready state. Methods for implementing I/O Multiplexing include select, poll, and epoll.

How I/O Multiplexing Works

A single thread registers multiple file descriptors.
The OS kernel monitors the state of registered file descriptors.
When an I/O operation becomes possible, the application is notified.
The application performs I/O operations in a non-blocking manner only on ready file descriptors.

I/O Multiplexing Implementation Methods

1. select

Used to handle multiple files in a single thread.
Uses an array that stores up to 1024 file descriptors, and searches for target file descriptors using sequential search, causing performance degradation as the number of file descriptors increases.
Compatible with older systems, but inefficient for modern requirements.

2. poll

Unlike select, which was limited to a maximum of 1024 FDs, poll can inspect an unlimited number of file descriptors.
Still uses sequential search, so performance degrades as the number of file descriptors increases, similar to select.

3. epoll

Supported only on Linux
Supports kernel-level multiplexing to overcome select's limitations.
Manages file descriptor state in the kernel and directly notifies state changes.
- Returns the list of changed file descriptors itself rather than just the count, eliminating the need to loop through files like select and poll, making it efficient.
Calling epoll_wait eliminates the need to pass monitoring target information every time.
Two modes:
- Level-Triggered: Continuously generates events while data remains in the input buffer. Keeps notifying as long as data exists.
- Edge-Triggered: Generates an event only at the moment data enters the input buffer.

4. IOCP (I/O Completion Port)

An API that efficiently processes large volumes of non-blocking sockets in Windows environments.
Features:
- Suitable for building high-performance servers.
- Efficiently manages multiple worker threads.
- Processes through notifications when I/O operations complete.

5. kqueue

An event notification mechanism used in BSD-family operating systems like FreeBSD and macOS.
Features:
- Can monitor various events including sockets, files, and timers.
- Efficiently manages asynchronous I/O events.

epoll vs IOCP vs kqueue

Item	epoll	IOCP	kqueue
Supported OS	Linux	Windows	FreeBSD, macOS, etc.
Purpose	Large-scale network I/O processing	Asynchronous I/O processing	Event-based I/O processing
Operation Method	Event-based asynchronous I/O processing	Notification queue for completed tasks	Event registration followed by notification
Event Management	epoll_wait()	GetQueuedCompletionStatus()	kevent()
Handling Unit	File Descriptor	I/O Handle	File Descriptor, socket, etc.
Performance	Optimized for large-scale client connections	CPU core-based optimization	Efficient with diverse event management
Features	Edge-triggered, Level-triggered support Simple API Scalable	Notification from work queue after I/O completion Suitable for high-performance servers Thread pool based	File I/O, timer, and other event support Multiplexing capable Flexible structure
Advantages	High scalability Can handle many connections	Optimized CPU utilization through thread pool management Suitable for large-scale task processing	Integrated management of multiple event sources Flexible and powerful functionality

Thread Pool

MinBapE — Thu, 13 Nov 2025 18:55:51 +0000

1. The Problem with Creating Threads Per Request

Ever implemented a server that creates a new thread for every request and destroys it when done? This approach has some critical issues you might not immediately notice.

Performance Issues
Thread creation is an expensive operation. The OS has to allocate stack memory, set up execution context, and handle various initialization overhead.
Resource Exhaustion
When thousands of concurrent requests hit your server, an equal number of threads get created. Memory gets exhausted rapidly, and your system becomes unresponsive.

Thread Pool solves this elegantly.

2. Thread Pool

Thread Pool addresses these problems cleanly.

The core idea is simple:

Pre-create threads and keep them waiting
Assign work to idle threads when requests come in
Reuse threads instead of destroying them after work completes

Benefits

Performance Boost: Eliminates thread creation overhead
Resource Control: Pool size limits concurrent thread count
Stability: Thread count stays bounded even during traffic spikes

Think of it like a restaurant: instead of hiring a chef every time a customer orders, you keep N chefs on staff and distribute orders among them.

Architecture

A Thread Pool consists of 3 main components:

1. Worker Threads

N pre-created threads
Stay alive, waiting for work

2. Task Queue

Queue where pending tasks wait
Must be thread-safe (multiple threads access it)

3. Work Distribution Logic

Idle threads fetch tasks from the queue
After completing work, they loop back to check the queue

3. Code Example

Using a Thread Pool

// Create Thread Pool
size_t num_threads = std::thread::hardware_concurrency(); // CPU core count
ThreadPool pool(num_threads);

// Insert tasks into queue
for (int i = 0; i < 1000; i++) {
    pool.enqueue([i]() {
        processRequest(requests[i]);
    });
}
// Pool internally maintains only N threads while processing 1000 tasks

Basic Thread Pool Structure

class ThreadPool {
public:
    ThreadPool(size_t threads);
    ~ThreadPool();

    // Add task to queue
    template<class F>
    void enqueue(F&& f);

private:
    std::vector<std::thread> workers;           // Worker threads
    std::queue<std::function<void()>> tasks;    // Task queue

    std::mutex queue_mutex;                     // Protects queue
    std::condition_variable condition;          // Wait/notify threads
    bool stop;
};

DEV Community: MinBapE

Docker and Kubernetes

Introduction

What is Docker?

What is Kubernetes?

Summary

const and constexpr

Introduction

const

Characteristics

Limitations

constexpr

Reasons to Use

When to Use const vs constexpr?

When to use const

When to use constexpr

Summary

TCP Variable-Length Packet Handling

Introduction

Packet Boundary Problem

TCP is a Stream Protocol

1. Nagle's Algorithm

2. Network Layer

3. recv() Call Timing

Solution

Header + Payload Structure

Sending

Receiving

Source Code

Tags

Mutex and Lock Guard in C++

Mutex (Mutual Exclusion)

Lock Guard

lock_guard

unique_lock

scoped_lock

Smart Pointers

Memory Management in C/C++

Smart Pointer

Conclusion

I/O Multiplexing

Blocking I/O

Problems with Thread per Connection

I/O Multiplexing

How I/O Multiplexing Works

I/O Multiplexing Implementation Methods

epoll vs IOCP vs kqueue

Thread Pool

1. The Problem with Creating Threads Per Request

2. Thread Pool

3. Code Example

3. `recv()` Call Timing