mirror of
https://github.com/tokio-rs/tokio.git
synced 2025-09-28 12:10:37 +00:00
605708dca6
* Originally reported in alexcrichton/tokio-process#42 * The root cause appears to be due to two different PollEvented instances trying to consume readiness events from the same file descriptor. * Previously we would simply swallow any `AlreadyExists` errors when attempting to register the pipe receiver with the event loop. I'm not sure if this means the PollEvented wrapper wasn't fully registered to receive events, or maybe there is a potential race condition with how PollEvented consumes mio readiness events. Using a fresh/duplicate file descriptor appears to mitigate the issue, however. * I was also not able to reproduce the issue as an isolated test case so there is no regression test available within this crate (but we can add one in tokio-process)
tokio-signal
An implementation of Unix signal handling for Tokio
Usage
First, add this to your Cargo.toml:
[dependencies]
tokio-signal = "0.2"
Next you can use this in conjunction with the tokio and futures crates:
extern crate futures;
extern crate tokio;
extern crate tokio_signal;
use futures::{Future, Stream};
fn main() {
// Create an infinite stream of "Ctrl+C" notifications. Each item received
// on this stream may represent multiple ctrl-c signals.
let ctrl_c = tokio_signal::ctrl_c().flatten_stream();
// Process each ctrl-c as it comes in
let prog = ctrl_c.for_each(|()| {
println!("ctrl-c received!");
Ok(())
});
tokio::run(prog.map_err(|err| panic!("{}", err)));
}
License
This project is licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in tokio-signal by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.