mirror of
https://github.com/tokio-rs/tokio.git
synced 2026-08-15 00:00:15 +02:00
Ivan Petkov
c9ffd98b1e
* As observed in alexcrichton/tokio-signal#38, Signal instances can starve based on the order they are created in, and this ordering appears to be platform/OS specific * The crux of the issue is that we woud only *attempt* to broadcast any pending signals if we successfully read out at least one byte from the global pipe. * For reasons unclear to me, the affected Signal instance would get woken up after the signal handler writes to the global pipe, but it would immediately hit a WouldBlock error and give up, bypassing the broadcast attempt (even though the pending flag was correctly set). - Maybe this has to do with OS specifics with how the bytes are delivered (or not), or with some complex interaction with tokio and the pipe registration. It seems fishy since strace logs didn't show the signal handler pipe write fail either, but I'm all out of ideas * The fix appears simple: unconditionally attempt to broadcast any pending signals *any* time a Driver instance is woken up. * Since we perform an atomic check for each pending signal, we know that each (coalesced) signal broadcast will happen at most once. If we were supuriously woken up and no signals were pending, then nothing will be yielded to any pollers of Signal * The down side is that since each Signal instance polls a Driver instance, each poll to Signal will essentially perform N atomic operations (N = number of signals we support) in an attempt to broadcast any pending signals. - However, we can revisit optimizing this better in the future Fixes alexcrichton/tokio-signal#38
tokio-signal
An implementation of Unix signal handling for Tokio
Usage
First, add this to your Cargo.toml:
[dependencies]
tokio-signal = "0.1"
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.