signal_hook/low_level/pipe.rs
1//! Module with the self-pipe pattern.
2//!
3//! One of the common patterns around signals is to have a pipe with both ends in the same program.
4//! Whenever there's a signal, the signal handler writes one byte of garbage data to the write end,
5//! unless the pipe's already full. The application then can handle the read end.
6//!
7//! This has two advantages. First, the real signal action moves outside of the signal handler
8//! where there are a lot less restrictions. Second, it fits nicely in all kinds of asynchronous
9//! loops and has less chance of race conditions.
10//!
11//! This module offers premade functions for the write end (and doesn't insist that it must be a
12//! pipe ‒ anything that can be written to is fine ‒ sockets too, therefore `UnixStream::pair` is a
13//! good candidate).
14//!
15//! If you want to integrate with some asynchronous library, plugging streams from `mio-uds` or
16//! `tokio-uds` libraries should work.
17//!
18//! If it looks too low-level for your needs, the [`iterator`][crate::iterator] module contains some
19//! higher-lever interface that also uses a self-pipe pattern under the hood.
20//!
21//! # Correct order of handling
22//!
23//! A care needs to be taken to avoid race conditions, especially when handling the same signal in
24//! a loop. Specifically, another signal might come when the action for the previous signal is
25//! being taken. The correct order is first to clear the content of the pipe (read some/all data
26//! from it) and then take the action. This way a spurious wakeup can happen (the pipe could wake
27//! up even when no signal came after the signal was taken, because ‒ it arrived between cleaning
28//! the pipe and taking the action). Note that some OS primitives (eg. `select`) suffer from
29//! spurious wakeups themselves (they can claim a FD is readable when it is not true) and blocking
30//! `read` might return prematurely (with eg. `EINTR`).
31//!
32//! The reverse order of first taking the action and then clearing the pipe might lose signals,
33//! which is usually worse.
34//!
35//! This is not a problem with blocking on reading from the pipe (because both the blocking and
36//! cleaning is the same action), but in case of asynchronous handling it matters.
37//!
38//! If you want to combine setting some flags with a self-pipe pattern, the flag needs to be set
39//! first, then the pipe written. On the read end, first the pipe needs to be cleaned, then the
40//! flag and then the action taken. This is what the [`SignalsInfo`][crate::iterator::SignalsInfo]
41//! structure does internally.
42//!
43//! # Write collating
44//!
45//! While unlikely if handled correctly, it is possible the write end is full when a signal comes.
46//! In such case the signal handler simply does nothing. If the write end is full, the read end is
47//! readable and therefore will wake up. On the other hand, blocking in the signal handler would
48//! definitely be a bad idea.
49//!
50//! However, this also means the number of bytes read from the end might be lower than the number
51//! of signals that arrived. This should not generally be a problem, since the OS already collates
52//! signals of the same kind together.
53//!
54//! # Examples
55//!
56//! This example waits for at last one `SIGUSR1` signal to come before continuing (and
57//! terminating). It sends the signal to itself, so it correctly terminates.
58//!
59//! ```rust
60//! use std::io::{Error, Read};
61//! use std::os::unix::net::UnixStream;
62//!
63//! use signal_hook::consts::SIGUSR1;
64//! use signal_hook::low_level::{pipe, raise};
65//!
66//! fn main() -> Result<(), Error> {
67//! let (mut read, write) = UnixStream::pair()?;
68//! pipe::register(SIGUSR1, write)?;
69//! // This will write into the pipe write end through the signal handler
70//! raise(SIGUSR1).unwrap();
71//! let mut buff = [0];
72//! read.read_exact(&mut buff)?;
73//! println!("Happily terminating");
74//! Ok(())
75//! }
76//! ```
77
78use std::io::{Error, ErrorKind};
79use std::os::unix::io::{AsRawFd, IntoRawFd, RawFd};
80
81use libc::{self, c_int};
82
83use crate::SigId;
84
85#[cfg(target_os = "aix")]
86const MSG_NOWAIT: i32 = libc::MSG_NONBLOCK;
87#[cfg(not(target_os = "aix"))]
88const MSG_NOWAIT: i32 = libc::MSG_DONTWAIT;
89
90#[derive(Copy, Clone)]
91pub(crate) enum WakeMethod {
92 Send,
93 Write,
94}
95
96struct WakeFd {
97 fd: RawFd,
98 method: WakeMethod,
99}
100
101impl WakeFd {
102 /// Sets close on exec and nonblock on the inner file descriptor.
103 fn set_flags(&self) -> Result<(), Error> {
104 unsafe {
105 let flags = libc::fcntl(self.as_raw_fd(), libc::F_GETFL, 0);
106 if flags == -1 {
107 return Err(Error::last_os_error());
108 }
109 let flags = flags | libc::O_NONBLOCK | libc::O_CLOEXEC;
110 if libc::fcntl(self.as_raw_fd(), libc::F_SETFL, flags) == -1 {
111 return Err(Error::last_os_error());
112 }
113 }
114 Ok(())
115 }
116 fn wake(&self) {
117 wake(self.fd, self.method);
118 }
119}
120
121impl AsRawFd for WakeFd {
122 fn as_raw_fd(&self) -> RawFd {
123 self.fd
124 }
125}
126
127impl Drop for WakeFd {
128 fn drop(&mut self) {
129 unsafe {
130 libc::close(self.fd);
131 }
132 }
133}
134
135pub(crate) fn wake(pipe: RawFd, method: WakeMethod) {
136 unsafe {
137 // This writes some data into the pipe.
138 //
139 // There are two tricks:
140 // * First, the crazy cast. The first part turns reference into pointer. The second part
141 // turns pointer to u8 into a pointer to void, which is what write requires.
142 // * Second, we ignore errors, on purpose. We don't have any means to handling them. The
143 // two conceivable errors are EBADFD, if someone passes a non-existent file descriptor or
144 // if it is closed. The second is EAGAIN, in which case the pipe is full ‒ there were
145 // many signals, but the reader didn't have time to read the data yet. It'll still get
146 // woken up, so not fitting another letter in it is fine.
147 let data = b"X" as *const _ as *const _;
148 match method {
149 WakeMethod::Write => libc::write(pipe, data, 1),
150 WakeMethod::Send => libc::send(pipe, data, 1, MSG_NOWAIT),
151 };
152 }
153}
154
155/// Registers a write to a self-pipe whenever there's the signal.
156///
157/// In this case, the pipe is taken as the `RawFd`. It'll be closed on deregistration. Effectively,
158/// the function takes ownership of the file descriptor. This includes feeling free to set arbitrary
159/// flags on it, including file status flags (that are shared across file descriptors created by
160/// `dup`).
161///
162/// Note that passing the wrong file descriptor won't cause UB, but can still lead to severe bugs ‒
163/// like data corruptions in files. Prefer using [`register`] if possible.
164///
165/// Also, it is perfectly legal for multiple writes to be collated together (if not consumed) and
166/// to generate spurious wakeups (but will not generate spurious *bytes* in the pipe).
167///
168/// # Internal details
169///
170/// Internally, it *currently* does following. Note that this is *not* part of the stability
171/// guarantees and may change if necessary.
172///
173/// * If the file descriptor can be used with [`send`][libc::send], it'll be used together with
174/// [`MSG_DONTWAIT`][libc::MSG_DONTWAIT]. This is tested by sending `0` bytes of data (depending
175/// on the socket type, this might wake the read end with an empty message).
176/// * If it is not possible, the [`O_NONBLOCK`][libc::O_NONBLOCK] will be set on the file
177/// descriptor and [`write`][libc::write] will be used instead.
178pub fn register_raw(signal: c_int, pipe: RawFd) -> Result<SigId, Error> {
179 let res = unsafe { libc::send(pipe, &[] as *const _, 0, MSG_NOWAIT) };
180 let fd = match (res, Error::last_os_error().kind()) {
181 (0, _) | (-1, ErrorKind::WouldBlock) => WakeFd {
182 fd: pipe,
183 method: WakeMethod::Send,
184 },
185 _ => {
186 let fd = WakeFd {
187 fd: pipe,
188 method: WakeMethod::Write,
189 };
190 fd.set_flags()?;
191 fd
192 }
193 };
194 let action = move || fd.wake();
195 unsafe { super::register(signal, action) }
196}
197
198/// Registers a write to a self-pipe whenever there's the signal.
199///
200/// The ownership of pipe is taken and will be closed whenever the created action is unregistered.
201///
202/// Note that if you want to register the same pipe for multiple signals, there's `try_clone`
203/// method on many unix socket primitives.
204///
205/// See [`register_raw`] for further details.
206pub fn register<P>(signal: c_int, pipe: P) -> Result<SigId, Error>
207where
208 P: IntoRawFd + 'static,
209{
210 register_raw(signal, pipe.into_raw_fd())
211}
212
213#[cfg(test)]
214mod tests {
215 use std::io::Read;
216 use std::os::unix::net::{UnixDatagram, UnixStream};
217
218 use super::*;
219
220 // Note: multiple tests share the SIGUSR1 signal. This is fine, we only need to know the signal
221 // arrives. It's OK to arrive multiple times, from multiple tests.
222 fn wakeup() {
223 crate::low_level::raise(libc::SIGUSR1).unwrap();
224 }
225
226 #[test]
227 fn register_with_socket() -> Result<(), Error> {
228 let (mut read, write) = UnixStream::pair()?;
229 register(libc::SIGUSR1, write)?;
230 wakeup();
231 let mut buff = [0; 1];
232 read.read_exact(&mut buff)?;
233 assert_eq!(b"X", &buff);
234 Ok(())
235 }
236
237 #[test]
238 #[cfg(not(target_os = "haiku"))]
239 fn register_dgram_socket() -> Result<(), Error> {
240 let (read, write) = UnixDatagram::pair()?;
241 register(libc::SIGUSR1, write)?;
242 wakeup();
243 let mut buff = [0; 1];
244 // The attempt to detect if it is socket can generate an empty message. Therefore, do a few
245 // retries.
246 for _ in 0..3 {
247 let len = read.recv(&mut buff)?;
248 if len == 1 && &buff == b"X" {
249 return Ok(());
250 }
251 }
252 panic!("Haven't received the right data");
253 }
254
255 #[test]
256 fn register_with_pipe() -> Result<(), Error> {
257 let mut fds = [0; 2];
258 unsafe { assert_eq!(0, libc::pipe(fds.as_mut_ptr())) };
259 register_raw(libc::SIGUSR1, fds[1])?;
260 wakeup();
261 let mut buff = [0; 1];
262 unsafe { assert_eq!(1, libc::read(fds[0], buff.as_mut_ptr() as *mut _, 1)) }
263 assert_eq!(b"X", &buff);
264 Ok(())
265 }
266}