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

Support get signal sender pid in signal::recv #7148

Open
taikulawo opened this issue Feb 10, 2025 · 4 comments
Open

Support get signal sender pid in signal::recv #7148

taikulawo opened this issue Feb 10, 2025 · 4 comments
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-signal Module: tokio/signal

Comments

@taikulawo
Copy link

Is your feature request related to a problem? Please describe.
We want to know signal sender pid to do some logic.

Describe the solution you'd like
https://docs.rs/tokio/latest/tokio/signal/unix/struct.Signal.html#method.recv
change signature from

pub async fn recv(&mut self) -> Option<()>{}

to

pub async fn recv(&mut self) -> Option<SignalInfo>{}

SigInfo should have kernel siginfo_t##_pid
https://elixir.bootlin.com/linux/v6.13.1/source/include/uapi/asm-generic/siginfo.h#L40
Additional context
https://stackoverflow.com/questions/11508427/linux-c-upon-receiving-a-signal-is-it-possible-to-know-the-pid-of-the-sender

@taikulawo taikulawo added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Feb 10, 2025
@Darksonn Darksonn added the M-signal Module: tokio/signal label Feb 10, 2025
@Darksonn
Copy link
Contributor

cc @ipetkov

@ipetkov
Copy link
Member

ipetkov commented Feb 10, 2025

This would unfortunately require a breaking change, with the alternative being to introduce a new method to return the signal itself.

Though FWIW a signal handler will always fire on the signal it was registered with (and this cannot be changed after the fact), so the caller can always add their own wrapper to return the originally-registered-signal as a workaround

@Darksonn
Copy link
Contributor

Yes, a new API would probably be required.

Though FWIW a signal handler will always fire on the signal it was registered with (and this cannot be changed after the fact), so the caller can always add their own wrapper to return the originally-registered-signal as a workaround

Isn't this about getting the pid that sent the signal, rather than which signal it is?

@hamidrezakp
Copy link

hamidrezakp commented Feb 18, 2025

I'd like to implement this feature.
How would you like the API to look like? because the origin pid is not available in all signals.

One way is to return a SignalInfo struct with optional fields and also provide the raw siginfo_t struct as an unsafe ptr for other uses.

pub async fn recv(&mut self) -> Option<SignalInfo>

struct SignalInfo {
    raw: *const siginfo_t,
    pub origin: Option<SignalOrigin>
}

enum SignalOrigin {
    Kernel
    Process(pid)
}

impl SignalInfo {
    pub unsafe fn raw_ptr(&self) -> *const libc::siginfo_t
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-signal Module: tokio/signal
Projects
None yet
Development

No branches or pull requests

4 participants