Apply suggestions from code review

Co-authored-by: Schplee <24275329+Schplee@users.noreply.github.com>
Co-authored-by: liamwhite <liamwhite@users.noreply.github.com>

site/content/entry/yuzu-progress-report-apr-2022/index.md

@@ -154,7 +154,7 @@ The latest changes include:
 We must mention that while Skyline kernel support is basically finished, bugs in yuzu’s codebase prevent proper operation of the modding framework.
 For example, due to underlying emulation issues, [ARCropolis](https://github.com/Raytwo/ARCropolis) won’t work until `Project Gaia` is finished, and some of the changes previously mentioned need some fine tuning from our part to function properly.
 
-There’s yet more work to do, but we’re a lot closer. [I can see the finish line!](https://www.youtube.com/watch?v=IAAKG57ouyM)
+There’s yet more work to do, but we’re a lot closer. We can see the finish line!
 
 ## UI improvements
 
@@ -180,14 +180,14 @@ Both changes are extremely beneficial for bloated or size unoptimized desktop en
 The `+` is there because we want to leave the door open for newer revisions.
 
 {{< imgs
-	"./about.png| "
+	"./about.png| Screenshot of the yuzu About box"
   >}}
 
-Not stopping there, Taichi {{< gh-hovercard "8283" "brings cleanups and improvements to Flatpak builds" >}}, including using proper app ID, fixing some typos, and adding a launch parameter to make yuzu use the dedicated GPU by default on Linux instead of the integrated GPU.
+Not stopping there, Taichi {{< gh-hovercard "8283" "performed some cleanup and made improvements to Flatpak builds" >}}, including using proper app ID, fixing some typos, and adding a launch parameter to make yuzu use the dedicated GPU by default on Linux instead of the integrated GPU.
 
 [Docteh](https://github.com/Docteh) has also helped considerably in improving yuzu’s UI.
 
-With a bit of manual thinkering, they managed to bypass some Qt limitations in order to {{< gh-hovercard "8190" "display more readable hyperlinks" >}} over dark themes.
+With a bit of manual thinkering, they managed to bypass some Qt limitations in order to {{< gh-hovercard "8190" "display more readable hyperlinks" >}} in our dark themes.
 
 {{< single-title-imgs
 	"People seem to have forgotten what hyperlinks are for, just click them!"
@@ -195,8 +195,8 @@ With a bit of manual thinkering, they managed to bypass some Qt limitations in o
 	"./hyperlinkfix.png"
 >}}
 
-Thanks to a report from GillianMC from our [Discord server](https://discord.gg/u77vRWY), Docteh found out that some quirks in the Qt API caused the compatibility status of listed games to not be translated.
-The cause lies in QObject, you can find the specific details in the {{< gh-hovercard "8204" "pull request’s description" >}}. Now status is properly reported in the corresponding language.
+Thanks to a report from GillianMC in our [Discord server](https://discord.gg/u77vRWY), Docteh found out that some quirks in the Qt API caused the compatibility status of listed games to not be translated.
+The cause lies in QObject, you can find the specific details in the {{< gh-hovercard "8204" "pull request’s description" >}}. Now the status is properly reported in the corresponding language.
 
 {{< single-title-imgs
 	"Example in Spanish"
@@ -215,7 +215,7 @@ Someone, please send a warrant asking for the detention of Carmen Sandiego.
 
 ## Kernel and CPU emulation changes
 
-Ket's begin with two changes that happened in March.
+Let's begin with two changes that happened in March.
 
 Our resident bunnei rabbit continued his work on rewriting yuzu's kernel memory management to make it 
 accurate to the latest system updates. This time, he tackled and revamped {{< gh-hovercard "7974" "how the kernel code memory is mapped and unmapped" >}}.
@@ -229,9 +229,9 @@ With this change, yuzu's memory layout is now more closely matching the console.
 > A slab represents a contiguous piece of memory. A heap is a general term used for any memory that is
 allocated dynamically and randomly.
 
-So, slab heaps are basically pieces of memory dynamically allocated for guest kernel objects.
+The slab heap is the space used to store guest kernel objects.
 By moving these away from the host (PC) heap memory (RAM) to emulated guest (Switch) memory, we can ensure
-that the kernel objects never go beyond the system limits to cause memory leaks on the host (PC).
+that the kernel objects never go beyond the system limits and cause memory leaks on the host (PC).
 
 Thread local storage (TLS), the mechanism by which each thread in a given multithreaded process allocates storage for 
 thread-specific data, was also rewritten making it accurate to the latest HorizonOS behaviour.
@@ -245,13 +245,12 @@ The Switch's HorizonOS has various services that perform various tasks e.g Audio
 
 Previously we used to allocate one host thread per HLE service interface because -
 
-- some service routines need to block threads, and 
+- some service routines need to potentially wait a long time for completion, like network or filesystem access, and 
 - we don't support guest thread rescheduling from host threads.
 
-> A thread in block state will have to wait until an action can be completed.
-> exmaple needed
+> A thread which is blocked will have to wait until the action that blocked it, such as I/O or simply sleeping for some amount of time, completes.
 
-The issue with this approach was that since it's the host OS that schedules these threads, yuzu could end up creating dozens of threads for services and that could lead to weird behaviour particularly on systems with hardware limitations.
+The issue with this approach was that since it's the host (Windows or Linux) that schedules the service threads, yuzu could create weird behaviour particularly on systems with hardware limitations due to the spawning one thread per service and the sheer number of service implementations we emulate.
 
 With the rewrite, yuzu now has a single "default service thread" that is used for 99% of the service methods that are non-blocking.
 For the services that are time-sensitive and for those that need blocking, we still allow thread creation (e.g. Audio, BSD, FileSystem, nvdrv)
@@ -260,13 +259,13 @@ This brings down the service thread count from double digits to single digits, t
 Users with 4 thread CPUs (either 2 cores + HT/SMT, or 4 cores) should see performance and stability improvements on most games.
 
 Another battle for proper shutdown behaviour is fought and won.
-yuzu currently does not emulate multi-process capabilities of the HorizonOS kernel, however these still need to be managed.
-To begin, the HorizonOS services have a port (for both client and server) that is used as a channel of communication for multiprocess (between game process to the server process).
+yuzu currently does not emulate multi-process capabilities of the HorizonOS kernel, because it is not required to emulate any games. However, the multi-process APIs that are used by games still need to be managed in the way they expect.
+All HorizonOS services have a port (for both client and server) that is used as a channel of communication between the game process and service process.
 A session is opened for each communication interface for them both and they are managed by their respective kernel objects.
 When the game closes the client port, the service closes the server port, and everything is shut down.
 
 The issue with our previous implementation was that yuzu wasn't properly tracking all the `KServerPort` and `KServerSession` objects for each service.
-And because of this, the services weren't properly getting closed and they in turn were causing further issues.
+And because of this, the services weren't properly getting closed, which in turn was causing further issues.
 
 This originally worked fine, but was regressed when we migrated guest kernel objects to emulated guest memory, as we mentioned previously.
 bunnei figured out the issue and quickly {{< gh-hovercard "8165" "reimplemented how we track these kernel objects" >}}.