From 30e00348ee8b360a5bb33936edfd6b48aaba59a9 Mon Sep 17 00:00:00 2001 From: David Kellum Date: Mon, 25 Jun 2018 13:05:22 -0700 Subject: [PATCH] Replace hidden tokio::executor::thread_pool docs with deprecation note --- src/executor/mod.rs | 75 ++------------------------------------------- 1 file changed, 3 insertions(+), 72 deletions(-) diff --git a/src/executor/mod.rs b/src/executor/mod.rs index 8e62bc54fd8..3f5b038b840 100644 --- a/src/executor/mod.rs +++ b/src/executor/mod.rs @@ -44,79 +44,10 @@ pub mod current_thread; #[deprecated(since = "0.1.8", note = "use tokio-threadpool crate instead")] -#[doc(hidden)] +/// Re-exports of [`tokio-threadpool`], deprecated in favor of the crate. +/// +/// [`tokio-threadpool`]: https://docs.rs/tokio-threadpool/0.1 pub mod thread_pool { - //! Maintains a pool of threads across which the set of spawned tasks are - //! executed. - //! - //! [`ThreadPool`] is an executor that uses a thread pool for executing - //! tasks concurrently across multiple cores. It uses a thread pool that is - //! optimized for use cases that involve multiplexing large number of - //! independent tasks that perform short(ish) amounts of computation and are - //! mainly waiting on I/O, i.e. the Tokio use case. - //! - //! Usually, users of [`ThreadPool`] will not create pool instances. - //! Instead, they will create a [`Runtime`] instance, which comes with a - //! pre-configured thread pool. - //! - //! At the core, [`ThreadPool`] uses a work-stealing based scheduling - //! strategy. When spawning a task while *external* to the thread pool - //! (i.e., from a thread that is not part of the thread pool), the task is - //! randomly assigned to a worker thread. When spawning a task while - //! *internal* to the thread pool, the task is assigned to the current - //! worker. - //! - //! Each worker maintains its own queue and first focuses on processing all - //! tasks in its queue. When the worker's queue is empty, the worker will - //! attempt to *steal* tasks from other worker queues. This strategy helps - //! ensure that work is evenly distributed across threads while minimizing - //! synchronization between worker threads. - //! - //! # Usage - //! - //! Thread pool instances are created using [`ThreadPool::new`] or - //! [`Builder::new`]. The first option returns a thread pool with default - //! configuration values. The second option allows configuring the thread - //! pool before instantiating it. - //! - //! Once an instance is obtained, futures may be spawned onto it using the - //! [`spawn`] function. - //! - //! A handle to the thread pool is obtained using [`ThreadPool::sender`]. - //! This handle is **only** able to spawn futures onto the thread pool. It - //! is unable to affect the lifecycle of the thread pool in any way. This - //! handle can be passed into functions or stored in structs as a way to - //! grant the capability of spawning futures. - //! - //! # Examples - //! - //! ```rust - //! # extern crate tokio; - //! # extern crate futures; - //! # use tokio::executor::thread_pool::ThreadPool; - //! use futures::future::{Future, lazy}; - //! - //! # pub fn main() { - //! // Create a thread pool with default configuration values - //! let thread_pool = ThreadPool::new(); - //! - //! thread_pool.spawn(lazy(|| { - //! println!("called from a worker thread"); - //! Ok(()) - //! })); - //! - //! // Gracefully shutdown the threadpool - //! thread_pool.shutdown().wait().unwrap(); - //! # } - //! ``` - //! - //! [`ThreadPool`]: struct.ThreadPool.html - //! [`ThreadPool::new`]: struct.ThreadPool.html#method.new - //! [`ThreadPool::sender`]: struct.ThreadPool.html#method.sender - //! [`spawn`]: struct.ThreadPool.html#method.spawn - //! [`Builder::new`]: struct.Builder.html#method.new - //! [`Runtime`]: ../../runtime/struct.Runtime.html - pub use tokio_threadpool::{ Builder, Sender,