Merge pull request #1261 from cuviper/compounds

Improve grammar for compound words

Author: cuviper

README.md

@@ -36,13 +36,13 @@ fn sum_of_squares(input: &[i32]) -> i32 {
 into tasks; it will dynamically adapt for maximum performance. If you
 need more flexibility than that, Rayon also offers the [join] and
 [scope] functions, which let you create parallel tasks on your own.
-For even more control, you can create [custom threadpools] rather than
-using Rayon's default, global threadpool.
+For even more control, you can create [custom thread pools] rather than
+using Rayon's default, global thread pool.
 
 [Parallel iterators]: https://docs.rs/rayon/*/rayon/iter/index.html
 [join]: https://docs.rs/rayon/*/rayon/fn.join.html
 [scope]: https://docs.rs/rayon/*/rayon/fn.scope.html
-[custom threadpools]: https://docs.rs/rayon/*/rayon/struct.ThreadPool.html
+[custom thread pools]: https://docs.rs/rayon/*/rayon/struct.ThreadPool.html
 
 ## No data races
 

RELEASES.md

@@ -591,12 +591,12 @@ Thanks to all of the contributors for this release!
 # Release rayon 0.8.1 / rayon-core 1.2.0 (2017-06-14)
 
 - The following core APIs are being stabilized:
-  - `rayon::spawn()` -- spawns a task into the Rayon threadpool; as it
+  - `rayon::spawn()` -- spawns a task into the Rayon thread pool; as it
     is contained in the global scope (rather than a user-created
     scope), the task cannot capture anything from the current stack
     frame.
   - `ThreadPool::join()`, `ThreadPool::spawn()`, `ThreadPool::scope()`
-    -- convenience APIs for launching new work within a thread-pool.
+    -- convenience APIs for launching new work within a thread pool.
 - The various iterator adapters are now tagged with `#[must_use]`
 - Parallel iterators now offer a `for_each_with` adapter, similar to
   `map_with`.
@@ -640,13 +640,13 @@ Thanks to all of the contributors for this release!
   `spawn_future_async` -- which spawn tasks that cannot hold
   references -- to simply `spawn` and `spawn_future`, respectively.
 - We are now using the coco library for our deque.
-- Individual threadpools can now be configured in "breadth-first"
+- Individual thread pools can now be configured in "breadth-first"
   mode, which causes them to execute spawned tasks in the reverse
   order that they used to.  In some specific scenarios, this can be a
   win (though it is not generally the right choice).
 - Added top-level functions:
   - `current_thread_index`, for querying the index of the current worker thread within
-    its thread-pool (previously available as `thread_pool.current_thread_index()`);
+    its thread pool (previously available as `thread_pool.current_thread_index()`);
   - `current_thread_has_pending_tasks`, for querying whether the
     current worker that has an empty task deque or not. This can be
     useful when deciding whether to spawn a task.
@@ -759,7 +759,7 @@ releases) and hence they should be avoided for production code.
 - We now have (unstable) support for futures integration. You can use
   `Scope::spawn_future` or `rayon::spawn_future_async()`.
 - There is now a `rayon::spawn_async()` function for using the Rayon
-  threadpool to run tasks that do not have references to the stack.
+  thread pool to run tasks that do not have references to the stack.
 
 ### Contributors
 

rayon-core/README.md

@@ -1,8 +1,8 @@
-Rayon-core represents the "core, stable" APIs of Rayon: join, scope, and so forth, as well as the ability to create custom thread-pools with ThreadPool.
+Rayon-core represents the "core, stable" APIs of Rayon: join, scope, and so forth, as well as the ability to create custom thread pools with ThreadPool.
 
 Maybe worth mentioning: users are not necessarily intended to directly access rayon-core; all its APIs are mirrored in the rayon crate. To that end, the examples in the docs use rayon::join and so forth rather than rayon_core::join.
 
-rayon-core aims to never, or almost never, have a breaking change to its API, because each revision of rayon-core also houses the global thread-pool (and hence if you have two simultaneous versions of rayon-core, you have two thread-pools).
+rayon-core aims to never, or almost never, have a breaking change to its API, because each revision of rayon-core also houses the global thread pool (and hence if you have two simultaneous versions of rayon-core, you have two thread pools).
 
 Please see [Rayon Docs] for details about using Rayon.
 

rayon-core/src/broadcast/mod.rs

@@ -7,10 +7,10 @@ use std::sync::Arc;
 
 mod test;
 
-/// Executes `op` within every thread in the current threadpool. If this is
-/// called from a non-Rayon thread, it will execute in the global threadpool.
+/// Executes `op` within every thread in the current thread pool. If this is
+/// called from a non-Rayon thread, it will execute in the global thread pool.
 /// Any attempts to use `join`, `scope`, or parallel iterators will then operate
-/// within that threadpool. When the call has completed on each thread, returns
+/// within that thread pool. When the call has completed on each thread, returns
 /// a vector containing all of their return values.
 ///
 /// For more information, see the [`ThreadPool::broadcast()`] method.
@@ -25,7 +25,7 @@ where
     unsafe { broadcast_in(op, &Registry::current()) }
 }
 
-/// Spawns an asynchronous task on every thread in this thread-pool. This task
+/// Spawns an asynchronous task on every thread in this thread pool. This task
 /// will run in the implicit, global scope, which means that it may outlast the
 /// current stack frame -- therefore, it cannot capture any references onto the
 /// stack (you will likely need a `move` closure).

rayon-core/src/latch.rs

@@ -167,7 +167,7 @@ impl<'r> SpinLatch<'r> {
         }
     }
 
-    /// Creates a new spin latch for cross-threadpool blocking.  Notably, we
+    /// Creates a new spin latch for cross-thread-pool blocking.  Notably, we
     /// need to make sure the registry is kept alive after setting, so we can
     /// safely call the notification.
     #[inline]
@@ -324,7 +324,7 @@ pub(super) struct CountLatch {
 }
 
 enum CountLatchKind {
-    /// A latch for scopes created on a rayon thread which will participate in work-
+    /// A latch for scopes created on a rayon thread which will participate in work
     /// stealing while it waits for completion. This thread is not necessarily part
     /// of the same registry as the scope itself!
     Stealing {

rayon-core/src/lib.rs

@@ -14,7 +14,7 @@
 //!
 //! [`ThreadPool`] can be used to create your own thread pools (using [`ThreadPoolBuilder`]) or to customize the global one.
 //! Tasks spawned within the pool (using [`install()`][tpinstall], [`join()`][tpjoin], etc.) will be added to a deque,
-//! where it becomes available for work stealing from other threads in the local threadpool.
+//! where it becomes available for work stealing from other threads in the local thread pool.
 //!
 //! [tpinstall]: ThreadPool::install()
 //! [tpjoin]: ThreadPool::join()
@@ -24,7 +24,7 @@
 //! Rayon uses `std` APIs for threading, but some targets have incomplete implementations that
 //! always return `Unsupported` errors. The WebAssembly `wasm32-unknown-unknown` and `wasm32-wasi`
 //! targets are notable examples of this. Rather than panicking on the unsupported error when
-//! creating the implicit global threadpool, Rayon configures a fallback mode instead.
+//! creating the implicit global thread pool, Rayon configures a fallback mode instead.
 //!
 //! This fallback mode mostly functions as if it were using a single-threaded "pool", like setting
 //! `RAYON_NUM_THREADS=1`. For example, `join` will execute its two closures sequentially, since
@@ -38,8 +38,8 @@
 //!
 //! # Restricting multiple versions
 //!
-//! In order to ensure proper coordination between threadpools, and especially
-//! to make sure there's only one global threadpool, `rayon-core` is actively
+//! In order to ensure proper coordination between thread pools, and especially
+//! to make sure there's only one global thread pool, `rayon-core` is actively
 //! restricted from building multiple versions of itself into a single target.
 //! You may see a build error like this in violation:
 //!
@@ -104,7 +104,7 @@ use wasm_sync as sync;
 
 use self::registry::{CustomSpawn, DefaultSpawn, ThreadSpawn};
 
-/// Returns the maximum number of threads that Rayon supports in a single thread-pool.
+/// Returns the maximum number of threads that Rayon supports in a single thread pool.
 ///
 /// If a higher thread count is requested by calling `ThreadPoolBuilder::num_threads` or by setting
 /// the `RAYON_NUM_THREADS` environment variable, then it will be reduced to this maximum.
@@ -116,18 +116,18 @@ pub fn max_num_threads() -> usize {
 }
 
 /// Returns the number of threads in the current registry. If this
-/// code is executing within a Rayon thread-pool, then this will be
-/// the number of threads for the thread-pool of the current
+/// code is executing within a Rayon thread pool, then this will be
+/// the number of threads for the thread pool of the current
 /// thread. Otherwise, it will be the number of threads for the global
-/// thread-pool.
+/// thread pool.
 ///
 /// This can be useful when trying to judge how many times to split
 /// parallel work (the parallel iterator traits use this value
 /// internally for this purpose).
 ///
 /// # Future compatibility note
 ///
-/// Note that unless this thread-pool was created with a
+/// Note that unless this thread pool was created with a
 /// builder that specifies the number of threads, then this
 /// number may vary over time in future versions (see [the
 /// `num_threads()` method for details][snt]).
@@ -186,10 +186,10 @@ pub struct ThreadPoolBuilder<S = DefaultSpawn> {
     /// The stack size for the created worker threads
     stack_size: Option<usize>,
 
-    /// Closure invoked on worker thread start.
+    /// Closure invoked on worker-thread start.
     start_handler: Option<Box<StartHandler>>,
 
-    /// Closure invoked on worker thread exit.
+    /// Closure invoked on worker-thread exit.
     exit_handler: Option<Box<ExitHandler>>,
 
     /// Closure invoked to spawn threads.
@@ -208,7 +208,7 @@ pub struct Configuration {
     builder: ThreadPoolBuilder,
 }
 
-/// The type for a panic handling closure. Note that this same closure
+/// The type for a panic-handling closure. Note that this same closure
 /// may be invoked multiple times in parallel.
 type PanicHandler = dyn Fn(Box<dyn Any + Send>) + Send + Sync;
 
@@ -501,10 +501,10 @@ impl<S> ThreadPoolBuilder<S> {
         self
     }
 
-    /// Sets the number of threads to be used in the rayon threadpool.
+    /// Sets the number of threads to be used in the rayon thread pool.
     ///
     /// If you specify a non-zero number of threads using this
-    /// function, then the resulting thread-pools are guaranteed to
+    /// function, then the resulting thread pools are guaranteed to
     /// start at most this number of threads.
     ///
     /// If `num_threads` is 0, or you do not call this function, then
@@ -537,12 +537,12 @@ impl<S> ThreadPoolBuilder<S> {
     /// rayon, the spawn and exit handlers do not run for that thread.
     ///
     /// Note that the current thread won't run the main work-stealing loop, so jobs spawned into
-    /// the thread-pool will generally not be picked up automatically by this thread unless you
+    /// the thread pool will generally not be picked up automatically by this thread unless you
     /// yield to rayon in some way, like via [`yield_now()`], [`yield_local()`], or [`scope()`].
     ///
-    /// # Local thread-pools
+    /// # Local thread pools
     ///
-    /// Using this in a local thread-pool means the registry will be leaked. In future versions
+    /// Using this in a local thread pool means the registry will be leaked. In future versions
     /// there might be a way of cleaning up the current-thread state.
     pub fn use_current_thread(mut self) -> Self {
         self.use_current_thread = true;

rayon-core/src/registry.rs

@@ -139,7 +139,7 @@ pub(super) struct Registry {
     //
     // - if this is the global registry, there is a ref-count that never
     //   gets released.
-    // - if this is a user-created thread-pool, then so long as the thread-pool
+    // - if this is a user-created thread pool, then so long as the thread pool
     //   exists, it holds a reference.
     // - when we inject a "blocking job" into the registry with `ThreadPool::install()`,
     //   no adjustment is needed; the `ThreadPool` holds the reference, and since we won't
@@ -489,7 +489,7 @@ impl Registry {
     }
 
     /// If already in a worker-thread of this registry, just execute `op`.
-    /// Otherwise, inject `op` in this thread-pool. Either way, block until `op`
+    /// Otherwise, inject `op` in this thread pool. Either way, block until `op`
     /// completes and return its return value. If `op` panics, that panic will
     /// be propagated as well.  The second argument indicates `true` if injection
     /// was performed, `false` if executed directly.
@@ -569,13 +569,13 @@ impl Registry {
     ///
     /// Note that blocking functions such as `join` and `scope` do not
     /// need to concern themselves with this fn; their context is
-    /// responsible for ensuring the current thread-pool will not
+    /// responsible for ensuring the current thread pool will not
     /// terminate until they return.
     ///
-    /// The global thread-pool always has an outstanding reference
-    /// (the initial one). Custom thread-pools have one outstanding
+    /// The global thread pool always has an outstanding reference
+    /// (the initial one). Custom thread pools have one outstanding
     /// reference that is dropped when the `ThreadPool` is dropped:
-    /// since installing the thread-pool blocks until any joins/scopes
+    /// since installing the thread pool blocks until any joins/scopes
     /// complete, this ensures that joins/scopes are covered.
     ///
     /// The exception is `::spawn()`, which can create a job outside
@@ -588,7 +588,7 @@ impl Registry {
         assert!(previous != usize::MAX, "overflow in registry ref count");
     }
 
-    /// Signals that the thread-pool which owns this registry has been
+    /// Signals that the thread pool which owns this registry has been
     /// dropped. The worker threads will gradually terminate, once any
     /// extant work is completed.
     pub(super) fn terminate(&self) {
@@ -664,7 +664,7 @@ pub(super) struct WorkerThread {
 
 // This is a bit sketchy, but basically: the WorkerThread is
 // allocated on the stack of the worker on entry and stored into this
-// thread local variable. So it will remain valid at least until the
+// thread-local variable. So it will remain valid at least until the
 // worker is fully unwound. Using an unsafe pointer avoids the need
 // for a RefCell<T> etc.
 thread_local! {
@@ -703,8 +703,8 @@ impl WorkerThread {
         WORKER_THREAD_STATE.get()
     }
 
-    /// Sets `self` as the worker thread index for the current thread.
-    /// This is done during worker thread startup.
+    /// Sets `self` as the worker-thread index for the current thread.
+    /// This is done during worker-thread startup.
     unsafe fn set_current(thread: *const WorkerThread) {
         WORKER_THREAD_STATE.with(|t| {
             assert!(t.get().is_null());
@@ -917,7 +917,7 @@ unsafe fn main_loop(thread: ThreadBuilder) {
     Latch::set(&registry.thread_infos[index].primed);
 
     // Worker threads should not panic. If they do, just abort, as the
-    // internal state of the threadpool is corrupted. Note that if
+    // internal state of the thread pool is corrupted. Note that if
     // **user code** panics, we should catch that and redirect.
     let abort_guard = unwind::AbortIfPanic;
 
@@ -939,7 +939,7 @@ unsafe fn main_loop(thread: ThreadBuilder) {
 }
 
 /// If already in a worker-thread, just execute `op`.  Otherwise,
-/// execute `op` in the default thread-pool. Either way, block until
+/// execute `op` in the default thread pool. Either way, block until
 /// `op` completes and return its return value. If `op` panics, that
 /// panic will be propagated as well.  The second argument indicates
 /// `true` if injection was performed, `false` if executed directly.

rayon-core/src/scope/mod.rs

@@ -93,7 +93,7 @@ struct ScopeBase<'scope> {
 ///
 /// # A note on threading
 ///
-/// The closure given to `scope()` executes in the Rayon thread-pool,
+/// The closure given to `scope()` executes in the Rayon thread pool,
 /// as do those given to `spawn()`. This means that you can't access
 /// thread-local variables (well, you can, but they may have
 /// unexpected values).

rayon-core/src/sleep/README.md

@@ -158,7 +158,7 @@ is avoiding a race condition wherein:
 The JEC protocol largely prevents this, but due to rollover, this prevention is
 not complete. It is possible -- if unlikely -- that enough activity occurs for
 Thread A to observe the same JEC value that it saw when getting sleepy. If the
-new work being published came from *inside* the thread-pool, then this race
+new work being published came from *inside* the thread pool, then this race
 condition isn't too harmful. It means that we have fewer workers processing the
 work then we should, but we won't deadlock. This seems like an acceptable risk
 given that this is unlikely in practice.

rayon-core/src/spawn/mod.rs

@@ -4,7 +4,7 @@ use crate::unwind;
 use std::mem;
 use std::sync::Arc;
 
-/// Puts the task into the Rayon threadpool's job queue in the "static"
+/// Puts the task into the Rayon thread pool's job queue in the "static"
 /// or "global" scope. Just like a standard thread, this task is not
 /// tied to the current stack frame, and hence it cannot hold any
 /// references other than those with `'static` lifetime. If you want
@@ -99,7 +99,7 @@ where
     .into_static_job_ref()
 }
 
-/// Fires off a task into the Rayon threadpool in the "static" or
+/// Fires off a task into the Rayon thread pool in the "static" or
 /// "global" scope.  Just like a standard thread, this task is not
 /// tied to the current stack frame, and hence it cannot hold any
 /// references other than those with `'static` lifetime. If you want
@@ -110,7 +110,7 @@ where
 /// function], except that calls from the same thread
 /// will be prioritized in FIFO order. This is similar to the now-
 /// deprecated [`breadth_first`] option, except the effect is isolated
-/// to relative `spawn_fifo` calls, not all threadpool tasks.
+/// to relative `spawn_fifo` calls, not all thread-pool tasks.
 ///
 /// For more details on this design, see Rayon [RFC #1].
 ///