What is asynchronous programming, and why has it become central in modern concurrent systems?
Asynchronous programming is a style where code can initiate tasks that run independently of the main thread, allowing execution to continue without blocking and wait only for results when needed. It’s crucial because it enables high responsiveness (e.g., serving multiple clients, handling tasks like I/O or network requests) and efficient use of resources without costly thread management.
Describe the event-driven programming model and its typical control flow.
In event-driven programming, control flow is dictated by events (user input, messages, etc.). An event loop awaits events and dispatches them to handlers, which process the events. After handler execution, control returns to the event loop, ensuring the program remains responsive. No call stack persists between event handlers—each handler executes atomically.
What is the “never-blocking rule” for event-handlers?
Event handlers should never block or contain infinite loops. Blocking a handler would block the entire event loop, making the program unresponsive and preventing queued events from processing. Instead, long-running tasks should be offloaded asynchronously, generating new events upon completion.
Explain “callbacks” and “continuation-passing style”.
Callbacks are functions provided as arguments, executed when an asynchronous operation completes. In continuation-passing style (CPS), computation is split so every function receives another function (the continuation) to be called with its result. This eliminates reliance on the stack and enables async flows, prominent in evented systems and functional programming.
What are the main challenges and pitfalls of callback-based asynchronous code?
Callback hell (deeply nested callbacks, hard to maintain/read), loss of composability, difficulty in error handling, and fragmentation of control flow (“asynchronous spaghetti”). These problems hinder modularity, extensibility, and reasoning.
How do “promises” improve asynchronous programming over callbacks?
A Promise represents an eventual result from an asynchronous operation. It can be resolved or rejected once and provides a clean API to attach completion handlers. Promises allow chaining of async actions (flattening the callback pyramid), centralize error handling, and simplify sequencing or parallelism.
How is “Promise.all” different from “Promise.race” in JavaScript?
Promise.all allows several async actions to run in parallel and resolves when all are complete (or rejects if any fail); Promise.race resolves/rejects as soon as one member of the group does, useful for timeouts or “first response” scenarios.
What problems remain with promises?
Promises begin execution immediately (no control over scheduling/cancellation), don’t work naturally with loops, and cannot be cancelled once started, potentially wasting resources. Composition (e.g., parameter passing) can be tricky, and integrating with legacy callback-based code may introduce complexity.
Describe “async/await” and its main benefits.
Async/await is a language feature letting developers write asynchronous code in synchronous style. “async” functions always return Promises; “await” can pause (yield) within those functions until a Promise settles. This improves readability, enables error propagation via try/catch, supports loops, and modularizes async code.
What are “coroutines”, and how do they relate to asynchronous programming?
Coroutines are generalizations of subroutines that can pause (yield) execution and be resumed later. They allow multiple entry points and maintain local state across pauses. Coroutines enable lightweight concurrency, cooperative multitasking, and underpin async programming and event loops in languages like Python, Kotlin, Go.
Explain the “reactor pattern” and its role in high-performance networking.
The reactor pattern demultiplexes events from multiple sources (I/O, timers) using a single thread of control (“event loop” or “dispatcher”) and dispatches event handlers based on event type/source readiness. It is widely used in high-concurrency servers, e.g., Node.js, and decouples event sources from processing logic.
How does “reactive programming” differ from classic async/event-driven programming?
Reactive programming is oriented around data flows and propagation of change—system components automatically react/update when dependencies change. Unlike classic event-driven async code, which requires manual state propagation between handlers, reactive programming abstracts away explicit control flow and lets the system maintain consistency reactively.
What are the basic abstractions in reactive programming?
- Observable/Event stream: Represents discrete, asynchronous data/events over time.
- Behaviours/Signals: Represent continuous values over time.
Both support operators for composition, filtering, transformation, combination, and subscription.
Explain “push” vs. “pull” evaluation models in reactive systems.
- Push: Data producers actively send updates to consumers; propagation occurs as soon as data changes (“eager”).
- Pull: Consumers request new data when needed (“lazy”); computation happens only if demand exists.
Hybrid models (push-pull) exist for optimal backpressure and performance.
What is “backpressure”, and why is it important in reactive streams?
Backpressure is a flow-control mechanism allowing consumers to signal producers about their capacity—preventing memory overload and processing bottlenecks. Producers can buffer, batch, or drop events/data to match consumer speed, critical for scalable async pipeline design.
What’s the difference between “cold” and “hot” observables?
Cold observables initiate a new data stream for each subscriber (each gets all events from start); hot observables emit events regardless of subscribers, and late joiners only get data from their subscription point onwards.
What is the Observer pattern and how is it used in reactive programming?
The Observer pattern lets objects (“observers”) subscribe to another object (“subject”) for notifications of updates or changes. In reactive programming, observables notify subscribers automatically, enabling dataflow dependency propagation and event-driven design.
How do reactive libraries (e.g., RxJS, RxJava) support composition and error handling?
These libraries provide rich operators for composing streams (map, filter, merge, zip) and centralize error handling—exceptions propagate to subscribers, and operators can define custom recovery strategies (onErrorReturn, etc.). Declarative style enables complex event/data orchestration.
What is a “glitch” in reactive systems, and how can it be avoided?
A glitch is a momentary inconsistency during dependency graph updates, where computations may be performed before all dependencies are updated, leading to incorrect intermediate states. Avoiding glitches requires topological sorting of update propagation, ensuring all dependencies are recalculated before dependents.
What are the main challenges of integrating asynchronous and reactive programming with modularity, testing, and state management?
Complex control flow and fragmented error handling complicate modularity and extensibility. Testing is harder due to non-determinism of event arrival and order. Managing shared state or propagating change reliably across hierarchies demands disciplined design and solid abstraction (e.g., observables, state containers).
