Skip to content
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

Merged
merged 3 commits into from
Dec 5, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 15 additions & 2 deletions tokio/src/signal/unix.rs
Original file line number Diff line number Diff line change
Expand Up @@ -23,13 +23,25 @@ pub(crate) type OsStorage = Box<[SignalInfo]>;
impl Init for OsStorage {
fn init() -> Self {
// There are reliable signals ranging from 1 to 33 available on every Unix platform.
#[cfg(not(target_os = "linux"))]
#[cfg(not(any(target_os = "linux", target_os = "illumos")))]
let possible = 0..=33;

// On Linux, there are additional real-time signals available.
#[cfg(target_os = "linux")]
let possible = 0..=libc::SIGRTMAX();

// On illumos, signal numbers go up to 41 (SIGINFO). The list of signals
// hasn't changed since 2013. See
// https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/iso/signal_iso.h.
//
// illumos also has real-time signals, but (a) the number of real-time
// signals is actually configurable at runtime and (b) this capability
// isn't exposed by libc as of 0.2.167, so we don't support them at the
// moment. If support for real-time signals on illumos is desired, this
// code would have to be changed to accommodate that.
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

@sunshowers sunshowers Dec 3, 2024

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.

Copy link
Contributor Author

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.

#[cfg(target_os = "illumos")]
let possible = 0..=41;

possible.map(|_| SignalInfo::default()).collect()
}
}
Expand Down Expand Up @@ -130,7 +142,8 @@ impl SignalKind {
target_os = "freebsd",
target_os = "macos",
target_os = "netbsd",
target_os = "openbsd"
target_os = "openbsd",
target_os = "illumos"
))]
pub const fn info() -> Self {
Self(libc::SIGINFO)
Expand Down
38 changes: 38 additions & 0 deletions tokio/tests/signal_info.rs
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
Copy link
Contributor

Choose a reason for hiding this comment

The 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 sig.recv() once.

Was that the intent of this code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied this from the other tests, specifically:

let (fire, wait) = oneshot::channel();
// NB: simulate a signal coming in by exercising our signal handler
// to avoid complications with sending SIGINT to the test process
tokio::spawn(async {
wait.await.expect("wait failed");
send_signal(libc::SIGINT);
});

I agree that it doesn't make a difference in the narrow case of a single-threaded runtime.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #7015.


let _ = fire.send(());

sig.recv().await.expect("received SIGINFO signal");
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We expect tests to run with cargo test too, so we shouldn't use nextest specific features. Having a timeout sgtm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, done.

}
Loading