mirror of
https://github.com/tokio-rs/tokio.git
synced 2026-09-01 00:00:10 +02:00
David Kellum
c9532e49d7
* use dyn Trait syntax where appropriate recent rust nightly started warning that not using `dyn` was deprecated. This requires MSRV 1.27.0+. * rustfmt fallout from dyn additions * stop explicit allow of rust_2018_idioms * more dyn Trait syntax * drop tokio-macros from 0.1.x workspace Since tokio-macros specifies an edition=2018, we would otherwise require MSRV 1.31.0 to build/test it. And tokio-macros isn't used with tokio 0.1.x. * reactor: narrow tokio-io-pool dev dep to 0.1.4 Since 0.1.5-6 is now a edition=2018 crate, which has effective MSRV 1.31.0. * narrow tempfile dev-dep to avoid MSRV bump tempfile 3.1.0 pulls in rand 0.7.0 and is MSRV 1.32.0 * narrow flate2 dev-dep to avoid MSRV bump flate2 1.0.10-11 have MSRV 1.34.0. github refs: alexcrichton/flate2-rs#207 * fs: drop deprecated tempdir crate use in tests In particular because it pulls in old rand duplicates. Replace use with tempfile::tempdir() which has been available since tempfile 3.0.0. backport-of: #1312 * increase CI MSRV to 1.28.0
66 lines
2.6 KiB
Rust
66 lines
2.6 KiB
Rust
extern crate futures;
|
|
extern crate tokio;
|
|
extern crate tokio_signal;
|
|
|
|
use futures::{Future, Stream};
|
|
|
|
/// how many signals to handle before exiting
|
|
const STOP_AFTER: u64 = 10;
|
|
|
|
fn main() -> Result<(), Box<dyn std::error::Error>> {
|
|
// tokio_signal provides a convenience builder for Ctrl+C
|
|
// this even works cross-platform: linux and windows!
|
|
//
|
|
// `fn ctrl_c()` produces a `Future` of the actual stream-initialisation
|
|
// the `flatten_stream()` convenience method lazily defers that
|
|
// initialisation, allowing us to use it 'as if' it is already the
|
|
// stream we want, reducing boilerplate Future-handling.
|
|
let endless_stream = tokio_signal::ctrl_c().flatten_stream();
|
|
// don't keep going forever: convert the endless stream to a bounded one.
|
|
let limited_stream = endless_stream.take(STOP_AFTER);
|
|
|
|
// how many Ctrl+C have we received so far?
|
|
let mut counter = 0;
|
|
|
|
println!(
|
|
"This program is now waiting for you to press Ctrl+C {0} times.
|
|
* If running via `cargo run --example ctrl-c`, Ctrl+C also kills it, \
|
|
due to https://github.com/rust-lang-nursery/rustup.rs/issues/806
|
|
* If running the binary directly, the Ctrl+C is properly trapped.
|
|
Terminate by repeating Ctrl+C {0} times, or ahead of time by \
|
|
opening a second terminal and issuing `pkill -sigkil ctrl-c`",
|
|
STOP_AFTER
|
|
);
|
|
|
|
// Stream::for_each is a powerful primitive provided by the Futures crate.
|
|
// It turns a Stream into a Future that completes after all stream-items
|
|
// have been completed, or the first time the closure returns an error
|
|
let future = limited_stream.for_each(|()| {
|
|
// Note how we manipulate the counter without any fancy synchronisation.
|
|
// The borrowchecker realises there can't be any conflicts, so the closure
|
|
// can just capture it.
|
|
counter += 1;
|
|
println!(
|
|
"Ctrl+C received {} times! {} more before exit",
|
|
counter,
|
|
STOP_AFTER - counter
|
|
);
|
|
|
|
// return Ok-result to continue handling the stream
|
|
Ok(())
|
|
});
|
|
|
|
// Up until now, we haven't really DONE anything, just prepared
|
|
// now it's time to actually schedule, and thus execute, the stream
|
|
// on our event loop
|
|
// FIXME(1000): windows uses a global driver task which doesn't terminate
|
|
// on its own, so if we use block_on_all our application will never exit
|
|
//tokio::runtime::current_thread::block_on_all(future)?;
|
|
tokio::runtime::current_thread::Runtime::new()
|
|
.expect("failed to start runtime on current thread")
|
|
.block_on(future)?;
|
|
|
|
println!("Stream ended, quiting the program.");
|
|
Ok(())
|
|
}
|