# [−] [src] Crate tokio

A runtime for writing reliable network applications without compromising speed.

Tokio is an event-driven, non-blocking I/O platform for writing asynchronous applications with the Rust programming language. At a high level, it provides a few major components:

- Tools for working with asynchronous tasks, including synchronization primitives and channels and timeouts, sleeps, and intervals.
- APIs for performing asynchronous I/O, including TCP and UDP sockets, filesystem operations, and process and signal management.
- A runtime for executing asynchronous code, including a task scheduler, an I/O driver backed by the operating system's event queue (epoll, kqueue, IOCP, etc...), and a high performance timer.

Guide level documentation is found on the website.

# A Tour of Tokio

Tokio consists of a number of modules that provide a range of functionality essential for implementing asynchronous applications in Rust. In this section, we will take a brief tour of Tokio, summarizing the major APIs and their uses.

The easiest way to get started is to enable all features. Do this by enabling the `full` feature flag:

    tokio = { version = "1", features = ["full"] }

### Authoring applications

Tokio is great for writing applications and most users in this case shouldn't worry too much about what features they should pick. If you're unsure, we suggest going with `full` to ensure that you don't run into any road blocks while you're building your application.

#### Example

This example shows the quickest way to get started with Tokio.

    tokio = { version = "1", features = ["full"] }

### Authoring libraries

As a library author your goal should be to provide the lighest weight crate that is based on Tokio. To achieve this you should ensure that you only enable the features you need. This allows users to pick up your crate without having to enable unnecessary features.

#### Example

This example shows how you may want to import features for a library that just needs to `tokio::spawn` and use a `TcpStream`.

    tokio = { version = "1", features = ["rt", "net"] }

## Working With Tasks

Asynchronous programs in Rust are based around lightweight, non-blocking units of execution called tasks. The `tokio::task` module provides important tools for working with tasks:

- The `spawn` function and `JoinHandle` type, for scheduling a new task on the Tokio runtime and awaiting the output of a spawned task, respectively,
- Functions for running blocking operations in an asynchronous task context.

The `tokio::task` module is present only when the "rt" feature flag is enabled.

The `tokio::sync` module contains synchronization primitives to use when needing to communicate or share data. These include:

- channels (`oneshot`, `mpsc`, and `watch`), for sending values between tasks,
- a non-blocking `Mutex`, for controlling access to a shared, mutable value,
- an asynchronous `Barrier` type, for multiple tasks to synchronize before beginning a computation.

The `tokio::sync` module is present only when the "sync" feature flag is enabled.

The `tokio::time` module provides utilities for tracking time and scheduling work. This includes functions for setting timeouts for tasks, sleeping work to run in the future, or repeating an operation at an interval.

In order to use `tokio::time`, the "time" feature flag must be enabled.

Finally, Tokio provides a runtime for executing asynchronous tasks. Most applications can use the `#[tokio::main]` macro to run their code on the Tokio runtime. However, this macro provides only basic configuration options. As an alternative, the `tokio::runtime` module provides more powerful APIs for configuring and managing runtimes. You should use that module if the `#[tokio::main]` macro doesn't provide the functionality you need.

Using the runtime requires the "rt" or "rt-multi-thread" feature flags, to enable the basic single-threaded scheduler and the thread-pool scheduler, respectively. See the `runtime` module documentation for details. In addition, the "macros" feature flag enables the `#[tokio::main]` and `#[tokio::test]` attributes.

## CPU-bound tasks and blocking code

Tokio is able to concurrently run many tasks on a few threads by repeatedly swapping the currently running task on each thread. However, this kind of swapping can only happen at `.await` points, so code that spends a long time without reaching an `.await` will prevent other tasks from running. To combat this, Tokio provides two kinds of threads: Core threads and blocking threads. The core threads are where all asynchronous code runs, and Tokio will by default spawn one for each CPU core. The blocking threads are spawned on demand, can be used to run blocking code that would otherwise block other tasks from running and are kept alive when not used for a certain amount of time which can be configured with `thread_keep_alive`. Since it is not possible for Tokio to swap out blocking tasks, like it can do with asynchronous code, the upper limit on the number of blocking threads is very large. These limits can be configured on the `Builder`.

To spawn a blocking task, you should use the `spawn_blocking` function.

    #[tokio::main]
    async fn main() {
        // This is running on a core thread.

        let blocking_task = tokio::task::spawn_blocking(|| {
            // This is running on a blocking thread.
            // Blocking here is ok.
        });

        // We can wait for the blocking task like this:
        // If the blocking task panics, the unwrap below will propagate the
        // panic.
        blocking_task.await.unwrap();
    }

If your code is CPU-bound and you wish to limit the number of threads used to run it, you should run it on another thread pool such as rayon. You can use an `oneshot` channel to send the result back to Tokio when the rayon task finishes.

## Asynchronous IO

As well as scheduling and running tasks, Tokio provides everything you need to perform input and output asynchronously.

The `tokio::io` module provides Tokio's asynchronous core I/O primitives, the `AsyncRead`, `AsyncWrite`, and `AsyncBufRead` traits. In addition, when the "io-util" feature flag is enabled, it also provides combinators and functions for working with these traits, forming as an asynchronous counterpart to `std::io`.

Tokio also includes APIs for performing various kinds of I/O and interacting with the operating system asynchronously. These include:

- `tokio::net`, which contains non-blocking versions of TCP, UDP, and Unix Domain Sockets (enabled by the "net" feature flag),
- `tokio::fs`, similar to `std::fs` but for performing filesystem I/O asynchronously (enabled by the "fs" feature flag),
- `tokio::signal`, for asynchronously handling Unix and Windows OS signals (enabled by the "signal" feature flag),
- `tokio::process`, for spawning and managing child processes (enabled by the "process" feature flag).

# Examples

A simple TCP echo server:

    use tokio::net::TcpListener;
    use tokio::io::{AsyncReadExt, AsyncWriteExt};

    #[tokio::main]
    async fn main() -> Result<(), Box<dyn std::error::Error>> {
        let listener = TcpListener::bind("127.0.0.1:8080").await?;

        loop {
            let (mut socket, _) = listener.accept().await?;

            tokio::spawn(async move {
                let mut buf = [0; 1024];

                // In a loop, read data from the socket and write the data back.
                loop {
                    let n = match socket.read(&mut buf).await {
                        // socket closed
                        Ok(n) if n == 0 => return,
                        Ok(n) => n,
                        Err(e) => {
                            eprintln!("failed to read from socket; err = {:?}", e);
                            return;
                        }
                    };

                    // Write the data back
                    if let Err(e) = socket.write_all(&buf[0..n]).await {
                        eprintln!("failed to write to socket; err = {:?}", e);
                        return;
                    }
                }
            });
        }
    }

## Feature flags

Tokio uses a set of feature flags to reduce the amount of compiled code. It is possible to just enable certain features over others. By default, Tokio does not enable any features but allows one to enable a subset for their use case. Below is a list of the available feature flags. You may also notice above each function, struct and trait there is listed one or more feature flags that are required for that item to be used. If you are new to Tokio it is recommended that you use the `full` feature flag which will enable all public APIs. Beware though that this will pull in many extra dependencies that you may not need.

- `full`: Enables all Tokio public API features listed below.
- `rt`: Enables `tokio::spawn`, the basic (current thread) scheduler, and non-scheduler utilities.
- `rt-multi-thread`: Enables the heavier, multi-threaded, work-stealing scheduler.
- `io-util`: Enables the IO based `Ext` traits.
- `io-std`: Enable `Stdout`, `Stdin` and `Stderr` types.
- `net`: Enables `tokio::net` types such as `TcpStream`, `UnixStream` and `UdpSocket`, as well as (on Unix-like systems) `AsyncFd`
- `time`: Enables `tokio::time` types and allows the schedulers to enable the built in timer.
- `process`: Enables `tokio::process` types.
- `macros`: Enables `#[tokio::main]` and `#[tokio::test]` macros.
- `sync`: Enables all `tokio::sync` types.
- `signal`: Enables all `tokio::signal` types.
- `fs`: Enables `tokio::fs` types.
- `test-util`: Enables testing based infrastructure for the Tokio runtime.

Note: `AsyncRead` and `AsyncWrite` traits do not require any features and are always available.

### Internal features

These features do not expose any new API, but influence internal implementation aspects of Tokio, and can pull in additional dependencies.

- `parking_lot`: As a potential optimization, use the parking_lot crate's synchronization primitives internally. MSRV may increase according to the parking_lot release in use.

### Unstable features

These feature flags enable unstable features. The public API may break in 1.x releases. To enable these features, the `--cfg tokio_unstable` must be passed to `rustc` when compiling. This is easiest done using the `RUSTFLAGS` env variable: `RUSTFLAGS="--cfg tokio_unstable"`.

- `tracing`: Enables tracing events.

## Modules

io | Traits, helpers, and type definitions for asynchronous I/O functionality.
net | TCP/UDP/Unix bindings for `tokio`.
runtime | The Tokio runtime.
stream | Due to the `Stream` trait's inclusion in `std` landing later than Tokio's 1.0 release, most of the Tokio stream utilities have been moved into the `tokio-stream` crate.
task | Asynchronous green-threads.
time | Utilities for tracking time.

## Macros

join | Wait on multiple concurrent branches, returning when all branches complete.
pin | Pins a value on the stack.
select | Wait on multiple concurrent branches, returning when the first branch completes, cancelling the remaining branches.
task_local | Declares a new task-local key of type `tokio::task::LocalKey`.
try_join | Wait on multiple concurrent branches, returning when all branches complete with `Ok(_)` or on the first `Err(_)`.

## Functions

spawn | Spawns a new asynchronous task, returning a `JoinHandle` for it.

## Attribute Macros

main | Marks async function to be executed by the selected runtime. This macro helps set up a `Runtime` without requiring the user to use Runtime or Builder directly.
test | Marks async function to be executed by runtime, suitable to test environment