Process lifecycle, resources allocation, lightweight executing structures, and thread pool design.

Process Architecture & States

Process & Thread Lifecycles

Why 10,000 threads will crash your server:

Memory Exhaustion (Out Of Memory): Each thread requires its own private stack segment. By default on Linux, stack size is 8MB (can be tuned down to 512KB-2MB). At 1MB per thread, 10,000 threads consume 10 GB of RAM just for stack frames, completely starving the application heap.
Context Switching Storm: If 10,000 threads compete for CPU cycles on an 8-core CPU, the CPU spends almost all its time swapping register states, page base pointers, and flushing caches (CPU thrashing). The CPU spends more time on context switching than running actual business logic.
Thread Creation Overhead: Initiating, scheduling, and tearing down 10,000 OS-level kernel threads wastes massive system cycles.

The Production-Grade Alternatives:

Thread Pool (Bounded Workers): Maintain a fixed pool of worker threads (e.g., `num_cores * 2`). Incoming requests are placed in a thread-safe task queue. Worker threads poll the queue, process requests, and return to the pool for reuse. This bounds resource usage.
Non-blocking Asynchronous I/O (Event Loop / Reactor Pattern): Used in Node.js, Nginx, Netty. A single thread (or one thread per core) multiplexes thousands of active connections using OS event notifications (such as `epoll` on Linux or `kqueue` on macOS). Instead of blocking a thread while waiting on disk/network I/O, the thread registers a callback and instantly moves to the next request. When I/O finishes, the OS raises an event and the thread executes the callback.