chore: Expand docs a little bit

docs/Writerside/hi.tree

@@ -9,4 +9,6 @@
     <toc-element topic="Setup-with-cargo-generate.md"/>
     <toc-element topic="Manual-setup.md"/>
     <toc-element topic="Use-with-analyze-all.md"/>
+    <toc-element topic="multithreading.md"/>
+    <toc-element topic="spawning-subprocesses.md"/>
 </instance-profile>

docs/Writerside/topics/Manual-setup.md

@@ -22,23 +22,12 @@ Make sure that:
 cargo install cargo-difftests
 ```
 
-- `cargo-difftests` supports 2 modes of collecting profiling data: For all crates, or for workspace crates only. In
-  practice, both of those work, but big projects that tend to have a lot of dependencies would generate substantially
-  larger profiles, which in turn makes their analysis much slower. So in general it is recommended to
-  only `-C instrument-coverage` workspace crates.
+## First, a bit on the rustc wrappers {id="rustc-wrapper-difftests"}
 
-<tabs group="coverage-area">
-<tab title="Coverage for all the crates" group-key="all">
-</tab>
-<tab title="Workspace-only coverage" group-key="workspace-only">
-In the case of workspace-only coverage, there is an additional package to install:
-
-```Bash
-cargo install rustc-wrapper-difftests
-```
-
-</tab>
-</tabs>
+`cargo-difftests` supports 2 modes of collecting profiling data: For all crates, or for workspace crates only. In
+practice, both of those work, but big projects that tend to have a lot of dependencies would generate substantially
+larger profiles, which in turn makes their analysis much slower. So in general it is recommended to
+only `-C instrument-coverage` workspace crates.
 
 ## Creating the `difftests` profile
 
@@ -135,6 +124,8 @@ The value it returns is quite important, here's what you have to keep in mind wh
 > let mut cmd = Command::new("...");
 > cmd.envs(difftests_env.env_for_children());
 > ```
+> 
+> More on this can be found in the [spawning subprocesses](spawning-subprocesses.md) article.
 {style="note"}
 
 ### `init` function parameters

docs/Writerside/topics/multithreading.md

@@ -0,0 +1,17 @@
+# On multithreading
+
+The way LLVM instrumentation works doesn't really lend itself well to the
+multi-threading of tests, so multiple tests cannot run at the same time.
+But a single test can spawn multiple threads, and the runtime will keep
+track of those threads as well.
+
+However, those extra threads *must* finish running before the test itself
+finishes. If they do not, and they are still going while the next test is
+executing, they *will* interfere with that test's coverage.
+
+This is not a problem if all the test code is single-threaded; however,
+special caution should be taken for multi-threaded tests.
+
+This however is different from spawning different processes, which is
+supported; see the article on spawning subprocesses that should be tracked
+[here](spawning-subprocesses.md).

docs/Writerside/topics/spawning-subprocesses.md

@@ -0,0 +1,30 @@
+# Spawning subprocesses
+
+You can go ahead and spawn subprocesses normally; if their
+coverage information should be ignored. If you however want them
+to be tracked, you should pass them some environment variables.
+
+## Environment variables
+
+You can pass the required environment variables to the subprocess
+like this:
+
+```Rust
+#[test]
+fn test_f() {
+    let env: DifftestsEnv = setup_difftests("test_f");
+    let mut cmd = std::process::Command::new("exe");
+    // the DifftestsEnv::env_for_children()
+    // method gives us the required environment variables
+    #[cfg(cargo_difftests)]
+    cmd.envs(env.env_for_children());
+    cmd.spawn().unwrap().wait().unwrap();
+}
+```
+
+The instrumented binaries must have had coverage enabled for this to work.
+
+Unlike with [multithreading](multithreading.md), the subprocesses can run
+even after the test has finished, and they will still be tracked. They
+only have to finish before the analysis. However, leaky tests are still
+a problem, and should be avoided.