From 8853612833107469bfb6700d6d637dedbf22ea78 Mon Sep 17 00:00:00 2001 From: asonix Date: Fri, 16 Feb 2024 09:49:28 -0600 Subject: [PATCH] machism -> mechanism --- content/003-the-crimson-chin.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/003-the-crimson-chin.md b/content/003-the-crimson-chin.md index 5a6d218..9bdb8e5 100644 --- a/content/003-the-crimson-chin.md +++ b/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?