Struct signal_hook::iterator::SignalsInfo
source · [−]pub struct SignalsInfo<E: Exfiltrator = SignalOnly>(_);
Expand description
The main structure of the module, representing interest in some signals.
Unlike the helpers in other modules, this registers the signals when created and unregisters them on drop. It provides the pending signals during its lifetime, either in batches or as an infinite iterator.
Most users will want to use it through the Signals
type alias for simplicity.
Multiple threads
Instances of this struct can be sent to other threads. In a multithreaded
application this can be used to dedicate a separate thread for signal handling. In this case
you should get a Handle
using the handle
method before sending the
Signals
instance to a background thread. With the handle you will be able to shut down the
background thread later, or to operatively add more signals.
The controller handle can be shared between as many threads as you like using its
clone
method.
Exfiltrators
The [SignalOnly]
provides only the signal number. There are further exfiltrators available in
the exfiltrator
module. Note that some of them are behind feature flags that need to be
enabled.
Examples
use signal_hook::consts::signal::*;
use signal_hook::iterator::Signals;
let mut signals = Signals::new(&[SIGUSR1, SIGUSR2])?;
let handle = signals.handle();
let thread = thread::spawn(move || {
for signal in &mut signals {
match signal {
SIGUSR1 => {},
SIGUSR2 => {},
_ => unreachable!(),
}
}
});
// Some time later...
handle.close();
thread.join().unwrap();
Implementations
sourceimpl<E: Exfiltrator> SignalsInfo<E>
impl<E: Exfiltrator> SignalsInfo<E>
sourcepub fn new<I, S>(signals: I) -> Result<Self, Error> where
I: IntoIterator<Item = S>,
S: Borrow<c_int>,
E: Default,
pub fn new<I, S>(signals: I) -> Result<Self, Error> where
I: IntoIterator<Item = S>,
S: Borrow<c_int>,
E: Default,
Creates the Signals
structure.
This registers all the signals listed. The same restrictions (panics, errors) apply as
for the Handle::add_signal
method.
sourcepub fn with_exfiltrator<I, S>(signals: I, exfiltrator: E) -> Result<Self, Error> where
I: IntoIterator<Item = S>,
S: Borrow<c_int>,
pub fn with_exfiltrator<I, S>(signals: I, exfiltrator: E) -> Result<Self, Error> where
I: IntoIterator<Item = S>,
S: Borrow<c_int>,
An advanced constructor with explicit Exfiltrator
.
sourcepub fn add_signal(&self, signal: c_int) -> Result<(), Error>
pub fn add_signal(&self, signal: c_int) -> Result<(), Error>
Registers another signal to the set watched by this Signals
instance.
The same restrictions (panics, errors) apply as for the Handle::add_signal
method.
sourcepub fn pending(&mut self) -> Pending<E>ⓘNotable traits for Pending<E>impl<E: Exfiltrator> Iterator for Pending<E> type Item = E::Output;
pub fn pending(&mut self) -> Pending<E>ⓘNotable traits for Pending<E>impl<E: Exfiltrator> Iterator for Pending<E> type Item = E::Output;
Returns an iterator of already received signals.
This returns an iterator over all the signal numbers of the signals received since last
time they were read (out of the set registered by this Signals
instance). Note that they
are returned in arbitrary order and a signal instance may returned only once even if it was
received multiple times.
This method returns immediately (does not block) and may produce an empty iterator if there are no signals ready.
sourcepub fn wait(&mut self) -> Pending<E>ⓘNotable traits for Pending<E>impl<E: Exfiltrator> Iterator for Pending<E> type Item = E::Output;
pub fn wait(&mut self) -> Pending<E>ⓘNotable traits for Pending<E>impl<E: Exfiltrator> Iterator for Pending<E> type Item = E::Output;
Waits for some signals to be available and returns an iterator.
This is similar to pending
. If there are no signals available, it
tries to wait for some to arrive. However, due to implementation details, this still can
produce an empty iterator.
This can block for arbitrary long time. If the Handle::close
method is used in
another thread this method will return immediately.
Note that the blocking is done in this method, not in the iterator.
sourcepub fn forever(&mut self) -> Forever<'_, E>ⓘNotable traits for Forever<'a, E>impl<'a, E: Exfiltrator> Iterator for Forever<'a, E> type Item = E::Output;
pub fn forever(&mut self) -> Forever<'_, E>ⓘNotable traits for Forever<'a, E>impl<'a, E: Exfiltrator> Iterator for Forever<'a, E> type Item = E::Output;
Get an infinite iterator over arriving signals.
The iterator’s next()
blocks as necessary to wait for signals to arrive. This is adequate
if you want to designate a thread solely to handling signals. If multiple signals come at
the same time (between two values produced by the iterator), they will be returned in
arbitrary order. Multiple instances of the same signal may be collated.
This is also the iterator returned by IntoIterator
implementation on &mut Signals
.
This iterator terminates only if explicitly closed.
Examples
use signal_hook::consts::signal::*;
use signal_hook::iterator::Signals;
let mut signals = Signals::new(&[SIGUSR1, SIGUSR2])?;
let handle = signals.handle();
thread::spawn(move || {
for signal in signals.forever() {
match signal {
SIGUSR1 => {},
SIGUSR2 => {},
_ => unreachable!(),
}
}
});
handle.close();
Trait Implementations
sourceimpl<E> Debug for SignalsInfo<E> where
E: Debug + Exfiltrator,
E::Storage: Debug,
impl<E> Debug for SignalsInfo<E> where
E: Debug + Exfiltrator,
E::Storage: Debug,
sourceimpl<'a, E: Exfiltrator> IntoIterator for &'a mut SignalsInfo<E>
impl<'a, E: Exfiltrator> IntoIterator for &'a mut SignalsInfo<E>
Auto Trait Implementations
impl<E = SignalOnly> !RefUnwindSafe for SignalsInfo<E>
impl<E> Send for SignalsInfo<E>
impl<E> Sync for SignalsInfo<E>
impl<E> Unpin for SignalsInfo<E>
impl<E = SignalOnly> !UnwindSafe for SignalsInfo<E>
Blanket Implementations
sourceimpl<T> BorrowMut<T> for T where
T: ?Sized,
impl<T> BorrowMut<T> for T where
T: ?Sized,
const: unstable · sourcefn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Mutably borrows from an owned value. Read more