Asynchronous programming is like placing an order before finding a table: the request starts, but the caller does not stand still until the result arrives. Work can be delegated to a device, thread, process, or external system; meanwhile, the program continues with other useful tasks. Completion or failure is reported later. Asynchrony describes how an operation call communicates, not one particular implementation. section 12.0 section 12.11
The motivating problem is waiting. A server that pauses for disk I/O, a network request, or another slow operation may waste time that could serve other requests. This is especially serious in an event-loop design: one blocking operation can stop the main thread from handling every other event. Asynchronous techniques arrange for the slow work to proceed without blocking that loop. section 12.1 section 12.12
An asynchronous call follows a simple pattern:
- Start work that may take time instead of retaining control until it finishes. section 13.1
- Let the initiating task execute other work while the delegated operation runs. section 12.11
- Resume handling when a result or error notification becomes available. section 12.11
This does not mean that asynchronous programming automatically makes every program faster. It adds complexity and can reduce maintainability. It is most useful when there are many largely independent tasks, the application spends much of its time waiting on I/O, and at least one task can usually make progress. Busy servers handling slow requests are a natural fit; tightly coordinated tasks that must constantly wait for one another are less attractive candidates. section 12.11
One implementation approach is cooperative multitasking. Tasks voluntarily yield control after a portion of work, allowing other tasks to run on a small number of threads. Coroutines represent work that can pause and later resume, while futures act as proxy objects for results that are not ready yet. Together, they can make asynchronous code read more like sequential code while still allowing many I/O-related tasks to share resources. section 12.12 section 12.6
Many independent web requests
Suppose an application needs results from several independent web requests. Rather than wait for request A before starting request B, it can scatter the requests as background tasks and gather their results through futures. The gathering step waits for the set of results when they are needed, while the individual requests have had an opportunity to progress concurrently. section 12.6
A useful design question is therefore not “Should everything be asynchronous?” but “What is waiting, and what useful work can proceed during that wait?” Keep blocking work away from an event loop, choose an implementation that fits the environment, and remember that asynchronous systems can be harder to write and debug without suitable libraries or frameworks. section 12.1 section 12.12
