Introduce the Tokio runtime: Reactor + Threadpool (#141)

This patch is an intial implementation of the Tokio runtime. The Tokio
runtime provides an out of the box configuration for running I/O heavy
asynchronous applications.

As of now, the Tokio runtime is a combination of a work-stealing thread
pool as well as a background reactor to drive I/O resources.

This patch also includes tokio-executor, a hopefully short lived crate
that is based on the futures 0.2 executor RFC.

* Implement `Park` for `Reactor`

This enables the reactor to be used as the thread parker for executors.
This also adds an `Error` component to `Park`. With this change, a
`Reactor` and a `CurrentThread` can be combined to achieve the
capabilities of tokio-core.
This commit is contained in:
Carl Lerche
2018-02-21 07:42:22 -08:00
committed by GitHub
parent e0d95aa037
commit fe14e7b127
32 changed files with 6344 additions and 966 deletions
+14 -15
View File
@@ -439,6 +439,8 @@ pub fn main() {
println!("accept error = {:?}", err);
});
println!("server running on localhost:6142");
// This starts the `current_thread` executor.
//
// Executors are responsible for scheduling many asynchronous tasks, driving
@@ -447,19 +449,16 @@ pub fn main() {
//
// The `current_thread` executor multiplexes all scheduled tasks on the
// current thread. This means that spawned tasks must not implement `Send`.
current_thread::run(|_| {
// Now, the server task must be spawned.
//
// It's important to note that all futures / tasks are lazy. No work
// will happen unless they are spawned onto an executor.
current_thread::spawn(server);
println!("server running on localhost:6142");
// The `current_thread::run` function will now block until *all* spawned
// tasks complete.
//
// In our example, we have not defined a shutdown strategy, so
// this will block until `ctrl-c` is pressed at the terminal.
});
// It's important to note that all futures / tasks are lazy. No work will
// happen unless they are spawned onto an executor.
//
// The executor will start running the `server` task, which, in turn, spawns
// new tasks for each incoming connection.
//
// The `current_thread::block_on_all` function will block until *all*
// spawned tasks complete.
//
// In our example, we have not defined a shutdown strategy, so this will
// block until `ctrl-c` is pressed at the terminal.
current_thread::block_on_all(server).unwrap();
}
+15 -17
View File
@@ -55,6 +55,8 @@ pub fn main() {
println!("accept error = {:?}", err);
});
println!("server running on localhost:6142");
// This starts the `current_thread` executor.
//
// Executors are responsible for scheduling many asynchronous tasks, driving
@@ -62,21 +64,17 @@ pub fn main() {
// implementations, each providing different scheduling characteristics.
//
// The `current_thread` executor multiplexes all scheduled tasks on the
// current thread. This means that spawned tasks are not required to
// implement `Send`.
current_thread::run(|_| {
// Now, the server task must be spawned.
//
// It's important to note that all futures / tasks are lazy. No work
// will happen unless they are spawned onto an executor.
current_thread::spawn(server);
println!("server running on localhost:6142");
// The `current_thread::run` function will now block until *all* spawned
// tasks complete.
//
// In our example, we have not defined a shutdown strategy, so
// this will block until `ctrl-c` is pressed at the terminal.
});
// current thread. This means that spawned tasks must not implement `Send`.
// It's important to note that all futures / tasks are lazy. No work will
// happen unless they are spawned onto an executor.
//
// The executor will start running the `server` task, which, in turn, spawns
// new tasks for each incoming connection.
//
// The `current_thread::block_on_all` function will block until *all*
// spawned tasks complete.
//
// In our example, we have not defined a shutdown strategy, so this will
// block until `ctrl-c` is pressed at the terminal.
current_thread::block_on_all(server).unwrap();
}