doc: fix typos

src/bench.rs

@@ -1,4 +1,4 @@
-//! The core benchmark functionalities.
+//! The core benchmark functionality.
 //!
 //! A benchmark in this crate actually refers to a group of benchmark runs, named **phases**. Users
 //! can provide one or multiple phases that will be run sequentially, each with different
@@ -32,7 +32,7 @@
 //!
 //! Options in `[global]` section can be overwritten via environment variables without changing the
 //! content in the TOML file.
-//! For example, if the user needs to override `x` in `[global]`, setting the envrionment variable
+//! For example, if the user needs to override `x` in `[global]`, setting the environment variable
 //! `global.x` will get the job done.
 //!
 //! ## Output Format
@@ -55,7 +55,7 @@
 //! all the benchmarks.
 //! - "total" followed by the total key-value operations executed by all worker threads in the
 //! repeat/phase.
-//! - "mops" followed by the thorughput in million operations per second of the repeat/phase.
+//! - "mops" followed by the throughput in million operations per second of the repeat/phase.
 
 use crate::stores::{BenchKVMap, BenchKVMapOpt};
 use crate::thread::{JoinHandle, Thread};
@@ -98,9 +98,9 @@ enum ReportMode {
     All,
 }
 
-/// The configuration of a single benchmark deserialized from a toml string.
+/// The configuration of a single benchmark deserialized from a TOML string.
 ///
-/// The fields are optional to ease parsing from toml, as there can be global parameters that are
+/// The fields are optional to ease parsing from TOML, as there can be global parameters that are
 /// set for them.
 #[derive(Deserialize, Clone, Debug)]
 pub struct BenchmarkOpt {
@@ -372,7 +372,7 @@ fn bench_phase_should_break(
 }
 
 struct Measurement {
-    /// An counter for each repeat in the same benchmark. Using AtomicU64 here makes the
+    /// An counter for each repeat in the same benchmark. Using [`AtomicU64`] here makes the
     /// measurement Sync + Send so it can be freely accessed by different threads (mainly by the
     /// thread that aggregates the overall measurement.) This value is actively updated and loosely
     /// read.
@@ -429,7 +429,7 @@ struct WorkerContext {
     /// Barrier that syncs all workers
     barrier: Arc<Barrier>,
 
-    /// (worker_id, nr_threads) pair, used to determine the identity of a worker and also
+    /// `(worker_id, nr_threads)` pair, used to determine the identity of a worker and also
     thread_info: (usize, usize),
 }
 
@@ -819,7 +819,7 @@ fn bench_phase_async(
 
 /// The real benchmark function for [`KVMap`].
 ///
-/// **You may not need to check this if it is ok to run benchmarks with [`std::thread`].**
+/// **You may not need to check this if it is OK to run benchmarks with [`std::thread`].**
 pub fn bench_regular(
     map: Arc<Box<impl KVMap + ?Sized>>,
     phases: &Vec<Arc<Benchmark>>,
@@ -842,7 +842,7 @@ pub fn bench_regular(
 
 /// The real benchmark function for [`AsyncKVMap`].
 ///
-/// **You may not need to check this if it is ok to run benchmarks with [`std::thread`].**
+/// **You may not need to check this if it is OK to run benchmarks with [`std::thread`].**
 pub fn bench_async(
     map: Arc<Box<impl AsyncKVMap + ?Sized>>,
     phases: &Vec<Arc<Benchmark>>,

src/lib.rs

@@ -44,7 +44,7 @@ pub trait KVMap: Send + Sync + 'static {
 
     /// The main bench method.
     ///
-    /// Users usually don't need to manually implement this method unless the implementor needs
+    /// Users usually don't need to manually implement this method unless the implementer needs
     /// custom thread spawn-join functions. If one would like to do so, it is needed to explicitly
     /// declare a new [`thread::Thread`] object and pass it to [`bench::bench_regular`].
     fn bench(self: Box<Self>, phases: &Vec<Arc<crate::bench::Benchmark>>) {
@@ -55,7 +55,7 @@ pub trait KVMap: Send + Sync + 'static {
 
     /// Start the main loop of KV server while using this map as the backend.
     ///
-    /// There is no need to manually implement this method unless the implementor needs custom
+    /// There is no need to manually implement this method unless the implementer needs custom
     /// thread spawn-join functions. If one would like to manually implement this method, it is
     /// needed to explicitly declare a new [`thread::Thread`] object and pass it to
     /// [`server::server_regular`].
@@ -131,7 +131,7 @@ pub struct Response {
 /// routine produces a response.
 ///
 /// Specifically, for benchmark, each worker thread maintains just one handle, so the buffer is
-/// per-worker. For server, each worker may manage multiple coneections. Each connection needs its
+/// per-worker. For server, each worker may manage multiple connections. Each connection needs its
 /// own responder (we should not mix responses for different connections, obviously). Therefore, it
 /// creates a handle for each incoming connection, and maintains a responder for it.
 pub trait AsyncKVMap: Sync + Send + 'static {

src/server.rs

@@ -61,7 +61,7 @@ pub(crate) fn serve_requests_async(
     handle.submit(requests);
 }
 
-/// Wrapper around TcpStream to enable multi-ownership in reader/writer for the same connection
+/// Wrapper around [`TcpStream`] to enable multi-ownership in reader/writer for the same connection
 #[derive(Clone)]
 struct RcTcpStream(Rc<TcpStream>);
 
@@ -114,7 +114,7 @@ impl BufRead for RequestReader {
 }
 
 /// Unlike reader, writer is registered to one or more handles. Therefore, it needs a cell to work,
-/// and potentially a wrapper rc.
+/// and potentially a wrapper [`Rc`].
 struct ResponseWriter(RefCell<BufWriter<RcTcpStream>>);
 
 impl ResponseWriter {
@@ -440,7 +440,7 @@ fn server_mainloop(
 
 /// The real server function for [`KVMap`].
 ///
-/// **You may not need to check this if it is ok to run benchmarks with [`std::thread`].**
+/// **You may not need to check this if it is OK to run benchmarks with [`std::thread`].**
 pub fn server_regular(
     map: Arc<Box<impl KVMap + ?Sized>>,
     host: &str,
@@ -481,7 +481,7 @@ pub fn server_regular(
 
 /// The real server function for [`AsyncKVMap`].
 ///
-/// **You may not need to check this if it is ok to run benchmarks with [`std::thread`].**
+/// **You may not need to check this if it is OK to run benchmarks with [`std::thread`].**
 pub fn server_async(
     map: Arc<Box<impl AsyncKVMap + ?Sized>>,
     host: &str,

src/stores/hashmap.rs

@@ -4,9 +4,9 @@ use parking_lot::{Mutex, RwLock};
 use serde::Deserialize;
 use std::sync::Arc;
 
-/// A wrapper around raw HashMap with variable-sized keys and values.
+/// A wrapper around raw [`HashMap`] with variable-sized keys and values.
 ///
-/// It is used as the builing block of other types. Note that this is not [`KVMap`].
+/// It is used as the building block of other types. Note that this is not [`KVMap`].
 pub type BaseHashMap = HashMap<Box<[u8]>, Box<[u8]>>;
 
 #[derive(Clone)]

src/stores/mod.rs

@@ -1,9 +1,9 @@
-//! The implementation of built-in key-value stores, and some util functions.
+//! The implementation of built-in key-value stores, and some helper functions.
 //!
 //! ## Configuration Format
 //!
 //! The configuration of a key-value store is stored in a dictionary named `map`. Therefore, a
-//! store's config file looks like the following:
+//! store's configuration file looks like the following:
 //!
 //! ```toml
 //! [map]
@@ -14,14 +14,14 @@
 //! ...
 //! ```
 //! The field `name` must be given and it should be equal to the name registered by the store.
-//! Other than `name`, all the fileds are parsed as a string map and will be hand over to the
+//! Other than `name`, all the fields are parsed as a string map and will be hand over to the
 //! constructor of the store's constructor function.
 //!
 //! ## Registering New Stores
 //!
 //! When users would like to dynamically register new key-value stores from their own crate, first
-//! of all, they need to implemement the corresponding [`KVMap`]/[`KVMapHandle`]
-//! (or [`AsyncKVMap`]/[`AsyncKVMapHandle`]) for the store. Then, they need to create a construcor
+//! of all, they need to implement the corresponding [`KVMap`]/[`KVMapHandle`]
+//! (or [`AsyncKVMap`]/[`AsyncKVMapHandle`]) for the store. Then, they need to create a constructor
 //! function with a signature of `fn(&toml::Table) -> BenchKVMap`.
 //!
 //! The final step is to register the store's constructor (along with its name) using
@@ -89,7 +89,7 @@ impl<'a> Registry<'a> {
 
 inventory::collect!(Registry<'static>);
 
-/// An aggregated option enum that can be parsed from a toml string. It contains all necessary
+/// An aggregated option enum that can be parsed from a TOML string. It contains all necessary
 /// parameters for each type of maps to be created.
 #[derive(Deserialize, Clone, Debug)]
 pub(crate) struct BenchKVMapOpt {

src/stores/null.rs

@@ -1,7 +1,7 @@
 use crate::stores::{BenchKVMap, Registry};
 use crate::*;
 
-/// NullMap does nothing. It can be used to measure overheads in the future.
+/// It does nothing. It can be used to measure overheads in the future.
 #[derive(Clone)]
 pub struct NullMap;
 

src/thread.rs

@@ -1,14 +1,14 @@
 //! Spawn-join functionality.
 //!
-//! **You may not need to check this if it is ok to run benchmarks with [`std::thread`].**
+//! **You may not need to check this if it is OK to run benchmarks with [`std::thread`].**
 //!
-//! A KVMap implementation is generally passive. However, some KVMap may act like a server with
+//! A [`KVMap`] implementation is generally passive. However, some store may act like a server with
 //! active threads. In that case, one may employ its own implementation of spawn-join. If that is
-//! the case, their join handle (like std::thread::JoinHandle) should implement the JoinHandle
-//! crate and the spawn struct needs to implement Spawn.
+//! the case, their join handle (like `[std::thread::JoinHandle`]) should implement the
+//! [`JoinHandle`] trait and the spawn struct needs to implement `[Spawn]`.
 //!
 //! Note that for simplicity, the function spawn is generic over should not have a return value. So
-//! it is with the JoinHandle. Because the purpose is not general spawn-join but solely for
+//! it is with the [`JoinHandle`]. Because the purpose is not general spawn-join but solely for
 //! benchmark code, which does not use any return values.
 
 pub trait JoinHandle {

src/workload.rs

@@ -8,7 +8,7 @@ use rand::Rng;
 use serde::Deserialize;
 use zipf::ZipfDistribution;
 
-/// OperationType is for internal use in the workload mod. It is essentially Operation without
+/// This is for internal use in the workload mod. It is essentially Operation without
 /// generated keys, values, or other parameters. They are generated based on a Mix defined below.
 #[derive(Clone)]
 enum OperationType {
@@ -51,7 +51,7 @@ enum KeyDistribution {
 }
 
 /// Key generator that takes care of synthetic keys based on a distribution. Currently it only
-/// generates fixed-sized keys based on the parameters of length and keyspace size.
+/// generates fixed-sized keys based on the parameters of length and key space size.
 #[derive(Debug)]
 struct KeyGenerator {
     len: usize,
@@ -111,7 +111,7 @@ impl KeyGenerator {
     }
 }
 
-/// A set of workload parameters that can be deserialized from a toml string.
+/// A set of workload parameters that can be deserialized from a TOML string.
 ///
 /// This struct is used for interacting with workload configuration files and also create new
 /// [`Workload`] instances.
@@ -155,7 +155,7 @@ pub struct WorkloadOpt {
     pub zipf_hotspot: Option<f64>,
 }
 
-/// The minimal unit of workload context with its access pattern (mix and kgen).
+/// The minimal unit of workload context with its access pattern (mix and key generator).
 ///
 /// The values generated internally are fixed-sized only for now, similar to the keys. To
 /// pressurize the