machism -> mechanism

content/003-the-crimson-chin.md

@@ -60,12 +60,12 @@ runtime, so let's pretend for now that the only runtimes that exist are tokio an
 The real distinction between tokio and async-std is how they attempt to figure out _when_ to try
 reading more bytes. In both cases, after failing to read bytes from the TcpStream, the runtime will
 register the TcpStream's file descriptor with an event mechanism. This mechanism is backed by a
-blocking IO operation, just like a blocking `read`, but unlike a blocking `read`, the event machism
-does not itself read any bytes, and it is capable of waiting for available bytes for many file
-descriptors simultaneously. This means that if your program has 30 TcpStreams, you can block waiting
-for any one of them to become available for reading on a single thread. Since this operation does
-block, tokio and async-std need to strike a balance between waiting for events on these registered
-file descriptors, and making progress on other asynchronous tasks.
+blocking IO operation, just like a blocking `read`, but unlike a blocking `read`, the event
+mechanism does not itself read any bytes, and it is capable of waiting for available bytes for many
+file descriptors simultaneously. This means that if your program has 30 TcpStreams, you can block
+waiting for any one of them to become available for reading on a single thread. Since this operation
+does block, tokio and async-std need to strike a balance between waiting for events on these
+registered file descriptors, and making progress on other asynchronous tasks.
 
 
 ## And that's why my crimson functions explode?