pub trait Timer<C>where
C: ComponentDefinition,{
// Required methods
fn schedule_once<F>(
&mut self,
timeout: Duration,
action: F,
) -> ScheduledTimer
where F: FnOnce(&mut C, ScheduledTimer) -> Result<Handled, HandlerError> + Send + 'static;
fn schedule_periodic<F>(
&mut self,
delay: Duration,
period: Duration,
action: F,
) -> ScheduledTimer
where F: Fn(&mut C, ScheduledTimer) -> Result<Handled, HandlerError> + Send + 'static;
fn cancel_timer(&mut self, handle: ScheduledTimer);
}Expand description
API exposed within a component by a timer implementation
This allows behaviours to be scheduled for later execution.
Required Methods§
Sourcefn schedule_once<F>(&mut self, timeout: Duration, action: F) -> ScheduledTimer
fn schedule_once<F>(&mut self, timeout: Duration, action: F) -> ScheduledTimer
Schedule the action to be run once after timeout expires
§Note
Depending on your system and the implementation used,
there is always a certain lag between the execution of the action
and the timeout expiring on the system’s clock.
Thus it is only guaranteed that the action is not run before
the timeout expires, but no bounds on the lag are given.
§Example
use kompact::prelude::*;
use std::time::Duration;
#[derive(ComponentDefinition, Actor)]
struct TimerComponent {
ctx: ComponentContext<Self>,
}
impl TimerComponent {
fn new() -> TimerComponent {
TimerComponent {
ctx: ComponentContext::uninitialised(),
}
}
}
impl ComponentLifecycle for TimerComponent {
fn on_start(&mut self) -> HandlerResult {
self.schedule_once(Duration::from_millis(10), move |new_self, _id| {
info!(new_self.log(), "Timeout was triggered!");
new_self.ctx().system().shutdown_async();
Handled::OK
});
Handled::OK
}
}
let system = KompactConfig::default().build().wait().expect("system");
let c = system.create(TimerComponent::new);
system.start(&c);
system.await_termination();Sourcefn schedule_periodic<F>(
&mut self,
delay: Duration,
period: Duration,
action: F,
) -> ScheduledTimer
fn schedule_periodic<F>( &mut self, delay: Duration, period: Duration, action: F, ) -> ScheduledTimer
Schedule the action to be run every timeout time units
The first time, the action will be run after delay expires,
and then again every timeout time units after.
§Note
Depending on your system and the implementation used,
there is always a certain lag between the execution of the action
and the timeout expiring on the system’s clock.
Thus it is only guaranteed that the action is not run before
the timeout expires, but no bounds on the lag are given.
§Example
use kompact::prelude::*;
use std::time::Duration;
#[derive(ComponentDefinition, Actor)]
struct TimerComponent {
ctx: ComponentContext<Self>,
counter: usize,
timeout: Option<ScheduledTimer>,
}
impl TimerComponent {
fn new() -> TimerComponent {
TimerComponent {
ctx: ComponentContext::uninitialised(),
counter: 0usize,
timeout: None,
}
}
}
impl ComponentLifecycle for TimerComponent {
fn on_start(&mut self) -> HandlerResult {
let timeout = self.schedule_periodic(
Duration::from_millis(10),
Duration::from_millis(100),
move |new_self, _id| {
info!(new_self.log(), "Timeout was triggered!");
new_self.counter += 1usize;
if new_self.counter > 10usize {
let timeout = new_self.timeout.take().expect("timeout");
new_self.cancel_timer(timeout);
new_self.ctx().system().shutdown_async();
}
Handled::OK
}
);
self.timeout = Some(timeout);
Handled::OK
}
// cleanup timeouts if shut down early, so they don't keep running
fn on_stop(&mut self) -> HandlerResult {
if let Some(timeout) = self.timeout.take() {
self.cancel_timer(timeout);
}
Handled::OK
}
fn on_kill(&mut self) -> HandlerResult {
if let Some(timeout) = self.timeout.take() {
self.cancel_timer(timeout);
}
Handled::OK
}
}
let system = KompactConfig::default().build().wait().expect("system");
let c = system.create(TimerComponent::new);
system.start(&c);
system.await_termination();Sourcefn cancel_timer(&mut self, handle: ScheduledTimer)
fn cancel_timer(&mut self, handle: ScheduledTimer)
Cancel the timer indicated by the handle
This method is asynchronous, and calling it is no guarantee than an already scheduled timeout is not going to fire before it is actually cancelled.
However, calling this method will definitely prevent periodic timeouts from being rescheduled.
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.