Eliza Weisman b8f63308d7
trace-core: Pass dispatcher by ref to dispatcher::with_default (#971)
* trace-core: Pass dispatcher by ref to `dispatcher::with_default`

As requested by @carllerche in https://github.com/tokio-rs/tokio/pull/966#discussion_r264380005, this branch changes the
`dispatcher::with_default` function in `tokio-trace-core` to take the
dispatcher by ref and perform the clone internally. This makes this
function more consistant with other `with_default` functions in other
crates.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

* trace: Don't set the default dispatcher on entering a span

Setting the default dispatcher on span entry is a relic of when spans
tracked their parent's ID. At that time, it was necessary to ensure that
any spans created inside a span were observed by the same subscriber
that originally provided the entered span with an ID, as otherwise, new
spans would be created with parent IDs that did not originate from that
subscriber.

Now that spans don't track their parent ID, this is no longer necessary.
However, removing this behavior does mean that if a span is entered
outside of the subscriber context it was created in, any subsequent
spans will be observed by the current default subscriber and thus will
not be part of the original span's trace tree. Since subscribers are not
expected to change frequently, and spans are not expected to move
between them, this is likely acceptable.

I've removed the tests for the old behavior.

Note that this change improves the performance of span entry/exit fairly
significantly. Here are the results of running a benchmark that enters
a span, does nothing, and immediately exits it, before this change:

```
test enter_span              ... bench:          93 ns/iter (+/- 14)
```

...and after:

```
test enter_span              ... bench:          51 ns/iter (+/- 9)
```

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
2019-03-11 15:29:00 -07:00
2019-03-01 09:12:21 -08:00
2019-03-01 21:04:43 -08:00
2019-02-24 15:41:26 -08:00
2019-03-01 21:04:43 -08:00
2019-03-01 21:04:43 -08:00
2019-03-01 21:04:43 -08:00
2019-03-01 21:04:43 -08:00
2019-03-01 21:04:43 -08:00
2019-01-06 23:25:55 -08:00
2019-03-01 21:04:43 -08:00

Tokio

A runtime for writing reliable, asynchronous, and slim applications with the Rust programming language. It is:

  • Fast: Tokio's zero-cost abstractions give you bare-metal performance.

  • Reliable: Tokio leverages Rust's ownership, type system, and concurrency model to reduce bugs and ensure thread safety.

  • Scalable: Tokio has a minimal footprint, and handles backpressure and cancellation naturally.

Crates.io MIT licensed Build Status Gitter chat

Website | Guides | API Docs | Chat

The API docs for the master branch are published here.

Overview

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:

  • A multithreaded, work-stealing based task scheduler.
  • A reactor backed by the operating system's event queue (epoll, kqueue, IOCP, etc...).
  • Asynchronous TCP and UDP sockets.

These components provide the runtime components necessary for building an asynchronous application.

Example

A basic TCP echo server with Tokio:

extern crate tokio;

use tokio::prelude::*;
use tokio::io::copy;
use tokio::net::TcpListener;

fn main() {
    // Bind the server's socket.
    let addr = "127.0.0.1:12345".parse().unwrap();
    let listener = TcpListener::bind(&addr)
        .expect("unable to bind TCP listener");

    // Pull out a stream of sockets for incoming connections
    let server = listener.incoming()
        .map_err(|e| eprintln!("accept failed = {:?}", e))
        .for_each(|sock| {
            // Split up the reading and writing parts of the
            // socket.
            let (reader, writer) = sock.split();

            // A future that echos the data and returns how
            // many bytes were copied...
            let bytes_copied = copy(reader, writer);

            // ... after which we'll print what happened.
            let handle_conn = bytes_copied.map(|amt| {
                println!("wrote {:?} bytes", amt)
            }).map_err(|err| {
                eprintln!("IO error {:?}", err)
            });

            // Spawn the future as a concurrent task.
            tokio::spawn(handle_conn)
        });

    // Start the Tokio runtime
    tokio::run(server);
}

More examples can be found here.

Getting Help

First, see if the answer to your question can be found in the [Guides] or the [API documentation]. If the answer is not there, there is an active community in the Tokio Gitter channel. We would be happy to try to answer your question. Last, if that doesn't work, try opening an issue with the question.

Contributing

🎈 Thanks for your help improving the project! We are so happy to have you! We have a contributing guide to help you get involved in the Tokio project.

Project layout

The tokio crate, found at the root, is primarily intended for use by application developers. Library authors should depend on the sub crates, which have greater guarantees of stability.

The crates included as part of Tokio are:

  • tokio-async-await: Experimental async / await support.

  • tokio-codec: Utilities for encoding and decoding protocol frames.

  • tokio-current-thread: Schedule the execution of futures on the current thread.

  • tokio-executor: Task execution related traits and utilities.

  • tokio-fs: Filesystem (and standard in / out) APIs.

  • tokio-io: Asynchronous I/O related traits and utilities.

  • tokio-reactor: Event loop that drives I/O resources (like TCP and UDP sockets).

  • tokio-tcp: TCP bindings for use with tokio-io and tokio-reactor.

  • tokio-threadpool: Schedules the execution of futures across a pool of threads.

  • tokio-timer: Time related APIs.

  • tokio-udp: UDP bindings for use with tokio-io and tokio-reactor.

  • tokio-uds: Unix Domain Socket bindings for use with tokio-io and tokio-reactor.

Supported Rust Versions

Tokio is built against the latest stable, nightly, and beta Rust releases. The minimum version supported is the stable release from three months before the current stable release version. For example, if the latest stable Rust is 1.29, the minimum version supported is 1.26. The current Tokio version is not guaranteed to build on Rust versions earlier than the minimum supported version.

License

This project is licensed under the MIT license.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Tokio by you, shall be licensed as MIT, without any additional terms or conditions.

Description
A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
Readme MIT 75 MiB
Languages
Rust 100%