1. 27

  2. 6

    For a comparison with what it used to be, see https://github.com/tokio-rs/tokio/pull/141/files?w=1 and look for src/lib.rs. The module docs have example code.

    The end-user code no longer requires choosing and starting a thread pool implementation, since Tokio picks a default for you.

    tokio::run spawns the future onto an executor (thread pool by default) and then blocks the current thread until the threads in the pool have shut down. The socket listener calls tokio::spawn and no longer needs to know if it’s posting to a thread pool or some other kind of executor.

    This line in the blog post confused me:

    1. Blocks the thread until the runtime becomes idle. The runtime becomes idle once all spawned futures have completed and all I/O resources bound to the reactor are dropped.

    It seems that a server with thread pool would continue polling indefinitely. There’s Runtime::shutdown_on_idle to shut down the runtime. I guess if using Tokio on the client side, that’d be where you’d want tokio::run to return ASAP, and you’d modify your future accordingly. Is my understanding correct?

    1. 5

      Very grateful for the work Tokio folks are doing.

      I used it not too long ago and it was a frustrating experience, and hard to find working examples (I guess because it was changing so fast.)

      So I’m glad that the simple use case is simple, while you can still use the individual building blocks if you have specific needs/once you are more familiar with it. Best of both worlds. 🙂