liveBook · Manning

Blocking

As explained in Refactoring to Rust

Blocking is execution behavior in which a process cannot proceed until a required resource or operation becomes available.

Blocking occurs when execution waits for a required resource or operation before continuing. Synchronous work makes one process wait for another; asynchronous processing allows independent work to continue without waiting for a response. section 8.2 section 9.3.1

A synchronous image loop

A Python loop creates eight images one after another, producing a local baseline of about 46 seconds. Each operation blocks the next until it finishes, motivating independent asynchronous work. section 8.2

Network requests provide another case: a call blocks while waiting for returned data, whereas an asynchronous call can switch to other work. A Rust search function uses asynchronous HTTP retrieval and response parsing. section 9.3.1

Listing 8.3 Console: Running multiple processes at once
python main.py & python main.py

Running two Python processes from the console provides a concrete contrast with work performed in a single blocking sequence. section 8.2

How Refactoring to Rust covers it

How deep it goes
Defines blocking through process and request waiting, then contrasts it with asynchronous processing without explaining scheduler internals.
Examples
Uses a Python Mandelbrot image loop, concurrent process commands, and an asynchronous Rust search request as concrete examples.
What you can do after
Diagnose synchronous waits and choose asynchronous processing when independent work should continue without waiting for responses.
How it connects
Connects blocking with synchronous processing, asynchronous processing, processes, network requests, and Rust asynchronous abilities.

Also explained in

Compare how 9 books explain blocking →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Refactoring to Rust. The section links point to the parts of the book it draws on.