6a:T49c,// Example of blocking system calls in C #include #include #include int main() { char buffer[1024]; ssize_t bytes_read; // This call BLOCKS the thread until data is available // The thread is moved to a wait queue by the kernel printf("About to block on read... "); bytes_read = read(STDIN_FILENO, buffer, sizeof(buffer)); // Execution resumes here ONLY after read() completes // Thread was not consuming CPU during the wait printf("Read %zd bytes ", bytes_read); return 0; } /* * What happens at the OS level during the blocking read(): * * 1. User process calls read() system call * 2. Kernel checks if data is available in the input buffer * 3. If no data: kernel moves thread to TASK_INTERRUPTIBLE state * 4. Thread is added to a wait queue for the terminal device * 5. Scheduler selects another thread to run (context switch) * 6. When data arrives: device driver signals the wait queue * 7. Kernel moves thread back to TASK_RUNNING state * 8. Thread is added back to the run queue * 9. Eventually scheduler runs the thread again * 10. read() returns with the data */6b:T50b,#include #include #include #include #include int main() { char buffer[1024]; ssize_t bytes_read; // Set stdin to non-blocking mode int flags = fcntl(STDIN_FILENO, F_GETFL, 0); fcntl(STDIN_FILENO, F_SETFL, flags | O_NONBLOCK); // Now read() returns immediately even if no data is available bytes_read = read(STDIN_FILENO, buffer, sizeof(buffer)); if (bytes_read == -1 && errno == EAGAIN) { // EAGAIN means "no data available, try again later" // The thread is NOT blocked - we can do other work! printf("No data available - would have blocked "); printf("But thread continues executing... "); // Do some other useful work here do_other_computation(); // Maybe try again later } else if (bytes_read > 0) { printf("Read %zd bytes immediately ", bytes_read); } return 0; } /* * Non-blocking I/O characteristics: * * - Returns immediately, never suspends the thread * - Returns EAGAIN/EWOULDBLOCK if operation would block * - Caller is responsible for retrying at appropriate times * - Enables single thread to handle multiple I/O streams * - Foundation for event-driven architectures */6c:T8d3,#include #include #include #include #include #include #include #include #define BUFFER_SIZE 65536 // Callback function invoked when AIO completes void aio_completion_handler(sigval_t sigval) { struct aiocb *req = (struct aiocb *)sigval.sival_ptr; // Check the result of the async operation int status = aio_error(req); if (status == 0) { ssize_t bytes = aio_return(req); printf("AIO completed: read %zd bytes ", bytes); // Data is NOW in the buffer - kernel already did the transfer process_data((char *)req->aio_buf, bytes); } else { printf("AIO error: %s ", strerror(status)); } } int main() { int fd = open("largefile.dat", O_RDONLY); if (fd < 0) { perror("open"); exit(1); } // Allocate buffer for the data char *buffer = malloc(BUFFER_SIZE); // Set up the async I/O control block struct aiocb cb; memset(&cb, 0, sizeof(cb)); cb.aio_fildes = fd; // File descriptor cb.aio_buf = buffer; // Buffer for data cb.aio_nbytes = BUFFER_SIZE; // How much to read cb.aio_offset = 0; // Where in file to read // Set up notification via thread callback cb.aio_sigevent.sigev_notify = SIGEV_THREAD; cb.aio_sigevent.sigev_notify_function = aio_completion_handler; cb.aio_sigevent.sigev_notify_attributes = NULL; cb.aio_sigevent.sigev_value.sival_ptr = &cb; // Submit the async read - THIS RETURNS IMMEDIATELY // The kernel will perform the read in the background if (aio_read(&cb) == -1) { perror("aio_read"); exit(1); } printf("AIO submitted - doing other work... "); // We can now do OTHER work while the kernel reads the file // This is the key advantage of true async I/O for (int i = 0; i < 10; i++) { printf("Working on task %d while read progresses... ", i); do_computation(i); } // Callback will fire automatically when I/O completes // In production: proper event loop or main thread coordination sleep(2); // Simplified: wait for completion free(buffer); close(fd); return 0; }6d:T4c2,// C: Manual async with epoll (Linux) // Explicit state machine management required #include #include #include #define MAX_EVENTS 1024 typedef struct { int fd; int state; // Manual state tracking char buffer[4096]; size_t bytes_read; } Connection; int main() { int epoll_fd = epoll_create1(0); struct epoll_event events[MAX_EVENTS]; while (1) { int nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1); for (int i = 0; i < nfds; i++) { Connection *conn = events[i].data.ptr; // Manual state machine for each connection switch (conn->state) { case STATE_READING: handle_read(conn); break; case STATE_PROCESSING: handle_process(conn); break; case STATE_WRITING: handle_write(conn); break; } } } } // Characteristics: // - Maximum control and performance // - Significant boilerplate and complexity // - Manual memory and state management // - Used in: nginx, Redis, high-performance servers6e:T4aa,# Python: asyncio with async/await # Event loop built into the language runtime import asyncio async def fetch_data(url: str) -> bytes: """Non-blocking HTTP fetch""" reader, writer = await asyncio.open_connection(url, 80) # await suspends THIS coroutine, not the thread # Other coroutines can run while we wait writer.write(f"GET / HTTP/1.1\r Host: {url}\r \r ".encode()) await writer.drain() data = await reader.read(4096) # Non-blocking read writer.close() await writer.wait_closed() return data async def main(): # Launch multiple requests CONCURRENTLY # Single thread, but all proceed simultaneously urls = ["example.com", "python.org", "github.com"] tasks = [fetch_data(url) for url in urls] # gather runs all tasks concurrently results = await asyncio.gather(*tasks) for url, data in zip(urls, results): print(f"{url}: {len(data)} bytes") # Run the async event loop asyncio.run(main()) # Characteristics: # - Built-in event loop and coroutine support # - async/await syntax for clean async code # - Single-threaded concurrency (GIL) # - Used in: web servers, API clients, data pipelines6f:T4bd,// JavaScript/Node.js: Promise-based async // Event loop is fundamental to the runtime const https = require('https'); const { promisify } = require('util'); // Wrap callback-based API in a Promise function fetchData(url) { return new Promise((resolve, reject) => { https.get(url, (res) => { let data = ''; res.on('data', chunk => data += chunk); res.on('end', () => resolve(data)); }).on('error', reject); }); } // Modern async/await usage async function main() { try { // All these initiate SIMULTANEOUSLY const [page1, page2, page3] = await Promise.all([ fetchData('https://example.com'), fetchData('https://nodejs.org'), fetchData('https://github.com') ]); console.log('All pages fetched concurrently!'); console.log(`Sizes: ${page1.length}, ${page2.length}, ${page3.length}`); } catch (error) { console.error('Fetch failed:', error); } } main(); // Characteristics: // - Single-threaded with event loop core // - Promises and async/await built-in // - Non-blocking I/O is the DEFAULT // - Used in: web servers, serverless, full-stack apps70:T57d,// Rust: Zero-cost async with tokio runtime // Compiles to state machines, no runtime overhead use tokio::net::TcpStream; use tokio::io::{AsyncReadExt, AsyncWriteExt}; async fn fetch_data(addr: &str) -> Result, std::io::Error> { let mut stream = TcpStream::connect(addr).await?; // await points are explicit suspension points // Rust compiler transforms this into a state machine stream.write_all(b"GET / HTTP/1.1\r \r ").await?; let mut buffer = vec![0u8; 4096]; let n = stream.read(&mut buffer).await?; buffer.truncate(n); Ok(buffer) } #[tokio::main] async fn main() { // Spawn concurrent tasks on the tokio runtime let handles: Vec<_> = ["127.0.0.1:80", "127.0.0.1:8080"] .iter() .map(|addr| { let addr = addr.to_string(); tokio::spawn(async move { fetch_data(&addr).await }) }) .collect(); // Await all tasks for handle in handles { match handle.await.unwrap() { Ok(data) => println!("Got {} bytes", data.len()), Err(e) => eprintln!("Error: {}", e), } } } // Characteristics: // - Zero-cost abstractions (no GC, no runtime overhead) // - Compiler transforms async into efficient state machines // - Pluggable runtimes (tokio, async-std) // - Used in: high-performance servers, embedded systems71:T44c,**Single-threaded async example:** ``` Time: |--0ms--|--1ms--|--2ms--|--3ms--|--4ms--|--5ms--|--6ms--|--7ms--| Thread 1: [Start A] [Start B] [Start C] [A done] [B done] [C done] | | | | | | +---------|---------|----------+ | | +---------|---------------------+ | +-------------------------------+ ↓ All I/O operations overlap in wall-clock time ↓ But only ONE thread is executing at any moment ``` **Multi-threaded parallel example:** ``` Time: |--0ms--|--1ms--|--2ms--|--3ms--| Thread 1: [=====COMPUTE A=====] Thread 2: [=====COMPUTE B=====] Thread 3: [=====COMPUTE C=====] ↓ All three threads execute SIMULTANEOUSLY ↓ Uses 3 CPU cores at once ``` **Combined async + parallel:** Modern systems often combine both: - Use async for I/O operations (network, disk) - Use parallelism for CPU-intensive work - Example: Web server with async I/O that dispatches CPU-bound tasks to a thread pool62:{"json":{"id":"seed_138ea30a87b2dc831e036d4006ed3617","slug":"asynchronous-programming","category":"Operating Systems","topic":"Concurrent Programming","title":"Asynchronous Programming","description":"Master asynchronous programming paradigms from the OS perspective. Explore async operations, callbacks, futures and promises, event loops, and async/await patterns—understanding how modern systems achieve high concurrency without thread explosion.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_9ee1a4d66acedb3d2bf3eb687533a80e","title":"Asynchronous Operations","order":0,"content":[{"id":"opening-hook","title":"The Waiting Problem","content":[{"data":{"content":"Imagine a restaurant where the chef prepares each dish one at a time—taking an order, cooking it completely, plating it, and serving it—before even looking at the next order. During a busy evening, customers would wait hours as the chef blocks on each individual dish.\n\nNow imagine a different model: the chef takes multiple orders, starts several dishes simultaneously, checks on cooking timers, delegates prep tasks to sous chefs, and orchestrates completion across many concurrent activities. The throughput increases dramatically without adding more chefs.\n\nThis is the fundamental distinction between **synchronous** and **asynchronous** operation. In computing, the synchronous model where operations block until completion creates the same bottleneck as our first chef. Asynchronous operations allow systems to initiate multiple activities, continue working on other tasks, and respond when those activities complete—dramatically improving throughput and responsiveness."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand what asynchronous operations are at the operating system level, how they differ from synchronous operations, the distinction between blocking and non-blocking I/O, and why async programming has become essential for building scalable, responsive systems.","variant":"info"},"type":"callout"}]},{"id":"sync-vs-async","title":"Synchronous vs Asynchronous Execution","content":[{"data":{"content":"At the most fundamental level, **synchronous** and **asynchronous** describe how operations relate to the flow of program execution.\n\n**Synchronous execution** means the caller initiates an operation and **waits**—the calling thread is suspended until the operation completes. The word 'synchronous' derives from Greek roots meaning 'same time'—the caller and the operation proceed together, in lockstep. The caller cannot proceed until the operation returns.\n\n**Asynchronous execution** means the caller initiates an operation and **continues immediately**—the operation proceeds independently while the caller does other work. The word 'asynchronous' means 'not at the same time'—the caller and the operation proceed on separate timelines. The caller is notified of completion through some mechanism (callback, polling, or signal)."},"type":"text"},{"data":{"rows":[["**Caller Behavior**","Blocks until operation completes","Continues immediately after initiating"],["**Thread Utilization**","Thread is idle during wait","Thread remains productive"],["**Control Flow**","Linear, sequential","Non-linear, requires coordination"],["**Result Retrieval**","Return value from function call","Callback, future, or polling"],["**Error Handling**","Traditional try-catch","Callback parameters or future inspection"],["**Code Complexity**","Simple, intuitive flow","More complex, requires explicit coordination"],["**Scalability**","Limited by thread availability","Can handle many concurrent operations"]],"caption":"Synchronous vs Asynchronous: Key Distinctions","headers":["Characteristic","Synchronous","Asynchronous"]},"type":"table"},{"data":{"content":"**A concrete example—reading a file:**\n\n*Synchronous approach:*\n```\ndata = read_file(\"/path/to/file\") // Thread blocks here\nprocess(data) // Executes after read completes\n```\n\n*Asynchronous approach:*\n```\nread_file_async(\"/path/to/file\", callback=process) // Returns immediately\ndo_other_work() // Executes while read proceeds\n// Later: process() is called when read completes\n```\n\nIn the synchronous model, `do_other_work()` cannot execute until `read_file` completes. In the asynchronous model, `do_other_work()` executes immediately, and `process()` is invoked later when the file read finishes."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Mental Model: Restaurant Orders","content":"Think of synchronous as placing an order and standing at the counter until it's ready (blocking). Asynchronous is placing an order, getting a buzzer, and sitting down to chat with friends—when the buzzer goes off, you pick up your food. The total preparation time is the same, but your time utilization is dramatically different.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"blocking-operations","title":"Understanding Blocking Operations","content":[{"data":{"content":"To truly understand asynchronous programming, we must first understand what **blocking** means at the operating system level.\n\nWhen a process or thread makes a **blocking system call**, the kernel moves that thread from the **ready queue** to a **wait queue** associated with the resource it's waiting for. The thread is no longer scheduled for CPU time—it's entirely suspended until the awaited event occurs.\n\n**Common blocking operations include:**\n\n- **Disk I/O**: Reading from or writing to files (waiting for disk head movement, sector reads)\n- **Network I/O**: Waiting for data from a socket (packets traveling over the network)\n- **User Input**: Waiting for keyboard, mouse, or other input devices\n- **Synchronization**: Waiting on a lock, semaphore, or condition variable\n- **Sleep**: Explicitly waiting for a timer to expire"},"type":"text"},{"data":{"code":"$6a","fileName":"blocking_syscall.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**The kernel wait queue mechanism:**\n\nThe kernel maintains **wait queues** for every resource that can cause blocking. When a thread blocks:\n\n1. **State transition**: Thread state changes from `RUNNING` to `INTERRUPTIBLE` (or `UNINTERRUPTIBLE` for non-abortable waits)\n2. **Queue insertion**: Thread is added to the wait queue for the specific resource\n3. **Context switch**: Scheduler immediately selects another ready thread\n4. **Zero CPU consumption**: Blocked thread uses no CPU cycles while waiting\n\nWhen the awaited event occurs (e.g., I/O completion):\n\n1. **Interrupt handler**: Hardware interrupt notifies the kernel\n2. **Wake up**: Kernel walks the wait queue and wakes all waiting threads\n3. **State transition**: Threads move from `INTERRUPTIBLE` to `RUNNING`\n4. **Scheduling**: Awakened threads compete for CPU time normally"},"type":"text"},{"data":{"icon":"Info","title":"Why Blocking Isn't Always Bad","content":"Blocking operations are efficient from a CPU perspective—a blocked thread consumes zero CPU cycles. The problem isn't CPU waste but *thread* waste. Each blocked thread ties up kernel resources (stack, scheduling structures, memory mappings). With limited threads available, blocking limits concurrency.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"non-blocking-io","title":"Non-Blocking I/O","content":[{"data":{"content":"**Non-blocking I/O** takes a different approach: instead of suspending the caller when an operation cannot complete immediately, the system call returns immediately with an indication that the operation is not yet complete.\n\nThe caller can then:\n- Retry the operation later (polling)\n- Proceed with other work and check periodically\n- Use an event notification mechanism to learn when to retry\n\n**The key insight**: Non-blocking I/O separates the *initiation* of an operation from the *completion*. The thread remains schedulable and can make progress on other tasks."},"type":"text"},{"data":{"code":"$6b","fileName":"non_blocking_io.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**EAGAIN and EWOULDBLOCK:**\n\nThese error codes are central to non-blocking I/O. They indicate that the operation cannot complete *right now* but is not an error—the caller should try again later when conditions change.\n\n- **EAGAIN**: \"Try again\" - temporary resource unavailability\n- **EWOULDBLOCK**: \"This would block\" - same meaning, some systems use this\n\nOn most modern systems, these are the same value. The semantics: \"What you asked for isn't ready, but it's not your fault and nothing's broken.\"\n\n**Non-blocking connects vs reads:**\n\nDifferent operations have different non-blocking behaviors:"},"type":"text"},{"data":{"rows":[["`read()`","Waits for data","Returns EAGAIN if no data"],["`write()`","Waits for buffer space","Returns EAGAIN if buffer full"],["`accept()`","Waits for connection","Returns EAGAIN if no pending connections"],["`connect()`","Waits for handshake","Returns EINPROGRESS, must poll for completion"]],"headers":["Operation","Blocking Behavior","Non-Blocking Behavior"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Polling Problem","content":"Naive non-blocking I/O with constant polling (busy-waiting) wastes CPU cycles checking if operations are ready. This is worse than blocking! The solution is event-driven I/O multiplexing (select, poll, epoll, kqueue) which we cover in the Event Loops page.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"asynchronous-io","title":"Asynchronous I/O (True Async)","content":[{"data":{"content":"There's an important distinction between **non-blocking I/O** and **true asynchronous I/O (AIO)**. They're often conflated, but the mechanisms differ significantly.\n\n**Non-blocking I/O** tells you that an operation *would block*, returning immediately. You must still perform the actual I/O operation yourself, typically when an event notifies you that the descriptor is ready.\n\n**Asynchronous I/O** initiates the entire operation in the kernel, which completes it in the background. The kernel notifies you when the data is already transferred—no additional read/write call is needed.\n\nThink of it this way:\n\n- **Blocking**: You ask someone to pour you coffee and wait for them.\n- **Non-blocking**: You check if coffee is ready; if not, you walk away and check later.\n- **Asynchronous**: You request coffee, go do other things, and someone brings it to you when ready."},"type":"text"},{"data":{"rows":[["**Blocking**","Synchronous","After wait","Function return","Good (thread sleeps)"],["**Non-blocking**","Immediate","Polling required","Poll result or event","Depends on polling strategy"],["**Async I/O**","Submit to kernel","Kernel performs I/O","Signal, callback, or queue","Excellent"]],"caption":"I/O Models Compared","headers":["Model","Initiation","Completion","Notification","CPU Efficiency"]},"type":"table"},{"data":{"code":"$6c","fileName":"posix_aio_example.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**Linux AIO implementations:**\n\nLinux has evolved through several async I/O implementations:\n\n**1. POSIX AIO (aio_read/aio_write)**\n- Portable but often implemented with thread pools\n- Not true kernel-level async on many systems\n- Signal or thread-based notification\n\n**2. Native Linux AIO (io_submit/io_getevents)**\n- True kernel-level async I/O\n- Works well for direct I/O (O_DIRECT)\n- Limited for buffered I/O\n\n**3. io_uring (Linux 5.1+)**\n- Modern, highly efficient async I/O\n- Submission and completion queues in shared memory\n- Near-zero overhead for high-frequency operations\n- Supports far more operation types than previous APIs"},"type":"text"},{"data":{"icon":"Zap","title":"io_uring: The Future of Linux Async I/O","content":"io_uring represents a paradigm shift in Linux I/O. By using ring buffers in shared memory between user and kernel space, it eliminates system call overhead for submissions and completions. A single io_uring can handle thousands of concurrent operations with minimal CPU usage.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"why-async-matters","title":"Why Async Matters: The C10K Problem","content":[{"data":{"content":"The importance of asynchronous programming crystallized around the **C10K problem**—the challenge of handling 10,000 concurrent connections on a single server. This problem, articulated by Dan Kegel in 1999, exposed the fundamental limitations of thread-per-connection architectures.\n\n**The thread-per-connection model:**\n\nIn traditional server designs, each client connection gets its own thread:\n\n```\nwhile (true) {\n client = accept(server_socket); // Block waiting for connection\n spawn_thread(handle_client, client);\n}\n\nvoid handle_client(socket) {\n while (true) {\n request = read(socket); // BLOCKS waiting for client\n response = process(request);\n write(socket, response); // BLOCKS until buffer available\n }\n}\n```\n\n**Why this breaks at scale:**"},"type":"text"},{"data":{"items":["**Memory overhead**: Each thread requires a stack (often 1-8 MB by default). 10,000 threads = 10-80 GB of stack memory alone.","**Context switch cost**: With 10,000 threads competing for finite CPUs, the OS spends significant time just switching between them.","**Scheduling overhead**: O(n) or O(log n) scheduling decisions for each context switch across 10,000 threads.","**Kernel structures**: Each thread has associated kernel data structures (task_struct in Linux: ~6KB each).","**Cache pollution**: Frequent context switches thrash CPU caches, destroying performance."],"title":{"icon":"AlertCircle","text":"Thread-Per-Connection Scalability Limits","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The math of thread limits:**"},"type":"text"},{"data":{"rows":[["100","800 MB","~1 GB","600 KB"],["1,000","8 GB","~10 GB","6 MB"],["10,000","80 GB","~100 GB","60 MB"],["100,000","800 GB","Impossible","600 MB"]],"headers":["Threads","Stack Size (8MB default)","Total Stack Memory","Kernel Overhead (~6KB/thread)"]},"type":"table"},{"data":{"content":"Even with reduced stack sizes (256KB), 10,000 threads consume 2.5 GB of stack memory. More critically, most of these threads are **blocked most of the time**, doing nothing but waiting for slow network I/O.\n\n**The async solution:**\n\nAsynchronous I/O inverts the model. Instead of one thread per connection, a small pool of threads (often equal to CPU cores) handles **all** connections:\n\n```\nwhile (true) {\n events = wait_for_events(); // Single syscall monitors ALL connections\n for event in events {\n if (event.type == READ_READY) {\n data = non_blocking_read(event.socket);\n process_data(event.socket, data);\n }\n if (event.type == WRITE_READY) {\n send_pending_data(event.socket);\n }\n }\n}\n```\n\nThis event-driven approach means:\n- 4 threads can handle 100,000 connections\n- Memory usage stays bounded (~300 bytes per connection state, not 8 MB)\n- No context-switch overhead between connection handlers\n- CPU time spent on actual work, not scheduling"},"type":"text"},{"data":{"icon":"CheckCircle","title":"The Modern Reality: C10M","content":"Today's challenge isn't C10K but C10M—10 million concurrent connections. Systems like nginx and HAProxy achieve this through aggressive use of async I/O, event loops, and careful memory management. A single modern server can handle more connections than entire data centers could in 1999.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"async-in-languages","title":"Async in Different Programming Languages","content":[{"data":{"content":"Different programming languages provide varying levels of async support, from manual callback management to sophisticated runtime systems. Understanding these differences helps you choose the right tool and understand what's happening beneath abstractions."},"type":"text"},{"data":{"tabs":[{"id":"c-async","badge":"Low-level","label":"C/C++","content":[{"data":{"code":"$6d","fileName":"async_c.c","showLineNumbers":true},"type":"code"}]},{"id":"python-async","badge":"asyncio","label":"Python","content":[{"data":{"code":"$6e","fileName":"async_python.py","showLineNumbers":true},"type":"code"}]},{"id":"js-async","badge":"Node.js","label":"JavaScript","content":[{"data":{"code":"$6f","fileName":"async_node.js","showLineNumbers":true},"type":"code"}]},{"id":"rust-async","badge":"tokio","label":"Rust","content":[{"data":{"code":"$70","fileName":"async_rust.rs","showLineNumbers":true},"type":"code"}]}]},"type":"tabs"},{"data":{"icon":"Info","title":"Language Runtime vs OS","content":"All these language-level async features ultimately rely on OS-level async primitives (epoll, kqueue, IOCP). The language runtime translates high-level async constructs into efficient system calls. Understanding the OS layer helps you debug performance issues that transcend any single language.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"async-vs-parallel","title":"Async vs Parallel: An Important Distinction","content":[{"data":{"content":"A common source of confusion is conflating **asynchronous** with **parallel**. These are related but distinct concepts.\n\n**Asynchronous**: Operations that don't block the calling thread. The operations *may or may not* run simultaneously—the key property is that the caller continues without waiting.\n\n**Parallel**: Operations that run **simultaneously** on multiple CPU cores. This requires multiple threads or processes executing at the same instant.\n\n**The key insight**: Async is about **waiting efficiently**, while parallel is about **computing simultaneously**."},"type":"text"},{"data":{"left":[{"data":{"items":["Single thread can handle many operations","Efficient for I/O-bound work","Operations interleave, not overlap","No additional CPU resources needed","Reduces waiting, not computing time","Example: Web server handling 10K connections"],"title":{"icon":"Zap","text":"Asynchronous","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Multiple threads/cores required","Efficient for CPU-bound work","Operations truly overlap in time","Requires multi-core hardware","Reduces computation time","Example: Rendering frames in a game"],"title":{"icon":"Target","text":"Parallel","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"$71"},"type":"text"},{"data":{"icon":"Lightbulb","title":"When to Use Which","content":"Use **async** when your bottleneck is waiting (I/O-bound): network requests, database queries, file operations. Use **parallelism** when your bottleneck is computation (CPU-bound): image processing, cryptography, simulations. Use **both** when you have mixed workloads.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Asynchronous Operations","content":[{"data":{"content":"We've established the foundation of asynchronous programming at the operating system level. Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Synchronous = Blocking**: The caller waits until the operation completes. Simple but limits concurrency.","**Asynchronous = Non-blocking**: The caller continues immediately. More complex but enables high concurrency.","**Blocking I/O** suspends threads in kernel wait queues—efficient for CPU but ties up threads.","**Non-blocking I/O** returns immediately with EAGAIN if not ready—requires polling or event notification.","**True Async I/O** (AIO, io_uring) submits operations to the kernel which completes them in the background.","**The C10K problem** drove async adoption—10,000 connections cannot each have a dedicated thread.","**Async ≠ Parallel**: Async is about waiting efficiently; parallel is about computing simultaneously."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nWith async operations understood, we need a mechanism to be notified when operations complete. The oldest and most fundamental pattern is the **callback**—a function passed to an async operation that's invoked upon completion. The next page explores callbacks in depth: their mechanics, patterns, and the problems they introduce."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand asynchronous operations at the OS level—the distinction between sync/async, blocking/non-blocking, and why async programming enables the high-concurrency systems that power the modern web. Next, we'll explore the callback pattern that makes async orchestration possible.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_31d069b8f415026cefef60116102469b","title":"Callbacks","order":1,"content":null,"isLocked":true},{"id":"seed_cf0b0ab0064c2776415b45e4d39bf66c","title":"Futures and Promises","order":2,"content":null,"isLocked":true},{"id":"seed_28e7b6716fd1a8c01003bc05a3a8c1d2","title":"Event Loops","order":3,"content":null,"isLocked":true},{"id":"seed_0af6a5d6e2ba5a8494c31178eaa78409","title":"Async/Await Patterns","order":4,"content":null,"isLocked":true}]}}