Blocking vs non-blocking

A blocking call: it does not return until the work is done. Recall from Unit 08 that calling a function pushes a stack frame, and the function returns when its work is finished — at which point its frame is popped and the caller continues at the next line.

A blocking call is a call that follows that rule even when the work is slow. The call to read a disk file does not return until the file’s bytes are actually in hand. The function’s stack frame stays on the stack the entire time the disk is working — ten milliseconds, ten million cycles — doing nothing, just occupying the stack.

This is “blocking” in the literal sense: the call blocks the line below it from running. Line 4 cannot start because line 3 has not returned. The whole program is frozen at that frame until the device answers. This is exactly the synchronous, sit-idle behaviour from lesson 01 — now seen at the level of a single function call.

A non-blocking call: it returns immediately. A non-blocking call is a call to a slow device that does not wait for the work to finish. It does only the quick part — hand the request to the device — and then returns right away, in a handful of cycles, long before the device has produced any answer.

So the function’s stack frame is pushed and almost immediately popped. The call returns, the caller continues to the next line, and the program keeps running. The disk read is now happening in the background, handled by the device itself, while the CPU moves on.

But this creates an obvious gap. The call returned before the data existed — so the call could not have given back the data the way an ordinary function returns a value. The result will exist only later, after the device finishes. The program needs some way to receive that result whenever it eventually shows up. That mechanism is the callback.

A callback: a function handed over to be run later. Recall from Unit 08 that a function is a named, reusable block of instructions, and that a function can be passed around as a value — given to other code by name.

A callback is exactly that: a function that your program writes and then hands to the non-blocking call, with the instruction “run this for me when the result is ready.” The program does not call the callback itself. It gives the callback away and walks on.

When the slow device finally finishes — milliseconds later — the result is delivered by calling the callback, passing the result in as an argument (Unit 08: arguments are the values handed to a function when it is called). The callback’s body then runs, with the data finally available. So the structure is split in two: the non-blocking call starts the work and returns; the callback contains the code that uses the result, and runs separately, later. The line “use the file” no longer sits right below “read the file” — it lives inside the callback instead.

The same task, the two ways. Take one concrete task: read a user’s name from disk, then greet them.

Blocking. Line 1: name = readFileBlocking("user.txt"). This call blocks — its frame sits on the stack for the full 10 ms. Only when the bytes arrive does it return, putting them in name. Line 2: print("Hello, " + name) runs next. Simple to read, but the CPU was frozen for 10 ms between the two lines.

Non-blocking. Line 1: readFileNonBlocking("user.txt", greet). This call hands the request to the disk and hands over greet as the callback, then returns immediately. Line 2 — whatever it is — runs right away; the CPU is not frozen. About 10 ms later the disk finishes, and greet is called with the name as its argument; greet’s body does the print.

Same task, same disk, same 10 ms of device time. The difference is whether the CPU spent those 10 ms frozen on a stuck frame (blocking) or running other lines while a callback waited its turn (non-blocking).