-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
signal: add SignalKind::info on illumos #6995
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,38 @@ | ||||||||||||||||||
#![warn(rust_2018_idioms)] | ||||||||||||||||||
#![cfg(feature = "full")] | ||||||||||||||||||
#![cfg(any( | ||||||||||||||||||
target_os = "dragonfly", | ||||||||||||||||||
target_os = "freebsd", | ||||||||||||||||||
target_os = "macos", | ||||||||||||||||||
target_os = "netbsd", | ||||||||||||||||||
target_os = "openbsd", | ||||||||||||||||||
target_os = "illumos" | ||||||||||||||||||
))] | ||||||||||||||||||
#![cfg(not(miri))] // No `sigaction` on Miri | ||||||||||||||||||
|
||||||||||||||||||
mod support { | ||||||||||||||||||
pub mod signal; | ||||||||||||||||||
} | ||||||||||||||||||
use support::signal::send_signal; | ||||||||||||||||||
|
||||||||||||||||||
use tokio::signal; | ||||||||||||||||||
use tokio::signal::unix::SignalKind; | ||||||||||||||||||
use tokio::sync::oneshot; | ||||||||||||||||||
|
||||||||||||||||||
#[tokio::test] | ||||||||||||||||||
async fn siginfo() { | ||||||||||||||||||
let mut sig = signal::unix::signal(SignalKind::info()).expect("installed signal handler"); | ||||||||||||||||||
|
||||||||||||||||||
let (fire, wait) = oneshot::channel(); | ||||||||||||||||||
|
||||||||||||||||||
// NB: simulate a signal coming in by exercising our signal handler | ||||||||||||||||||
// to avoid complications with sending SIGINFO to the test process | ||||||||||||||||||
tokio::spawn(async { | ||||||||||||||||||
wait.await.expect("wait failed"); | ||||||||||||||||||
send_signal(libc::SIGINFO); | ||||||||||||||||||
}); | ||||||||||||||||||
Comment on lines
+29
to
+34
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The oneshot channel changes nothing. Tests use the single-threaded runtime, so this spawned task is going to run on this thread, and it will not run until the main test task yields, which it does after polling Was that the intent of this code? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I copied this from the other tests, specifically: tokio/tokio/tests/signal_ctrl_c.rs Lines 19 to 26 in c032ea0
I agree that it doesn't make a difference in the narrow case of a single-threaded runtime. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would you like to keep the oneshot channel, have me remove it from this test, or do it yourself across all the signal tests? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Filed #7015. |
||||||||||||||||||
|
||||||||||||||||||
let _ = fire.send(()); | ||||||||||||||||||
|
||||||||||||||||||
sig.recv().await.expect("received SIGINFO signal"); | ||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we consider setting a (very long) timeout on this, so that the test failure mode if the signal is not received is a panic, rather than running forever? Just a thought. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I copied the other signal tests which don't set that kind of timeout, but it would certainly make sense to do so. Alternatively, the timeout could be set in nextest. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We expect tests to run with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. All right, done. |
||||||||||||||||||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for including the comment, this is lovely!
Out of interest, there wouldn't happen to be any libc ticket or similar tracking support for real-time issues? Not a big deal, but if there is something, it could be worth referencing that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I couldn't find a libc issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put up rust-lang/libc#4171 -- will update this comment with a link to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a link -- once it lands in upstream libc, it should be possible to do on illumos what's done on Linux.