zephyr::kio

Trait ContextExt

Source
pub trait ContextExt {
    // Required methods
    fn add_semaphore<'a>(
        &'a mut self,
        sem: &'a Semaphore,
        timeout: impl Into<Timeout>,
    );
    fn add_signal<'a>(
        &'a mut self,
        signal: &'a Signal,
        timeout: impl Into<Timeout>,
    );
    fn add_queue<'a>(
        &'a mut self,
        queue: &'a Queue,
        timeout: impl Into<Timeout>,
    );
    fn add_timeout(&mut self, timeout: impl Into<Timeout>);
}
Expand description

Extensions on Context to support scheduling via Zephyr’s workqueue system.

All of these are called from within the context of running work, and indicate what next should cause this work to be run again. If none of these methods are called before the work exits, the work will be scheduled to run after Forever, which is not useful. There may be later support for having a Waker that can schedule work from another context.

Note that the events to wait on, such as Semaphores or channels, if there are multiple threads that can wait for them, might cause this worker to run, but not actually be available. As such, to maintain the non-blocking requirements of Work, Semaphore::take, and the blocking send and recv operations on channels should not be used, even after being woken.

For the timeout Forever is useful to indicate there is no timeout. If called with NoWait, the work will be immediately scheduled. In general, it is better to query the underlying object directly rather than have the overhead of being rescheduled.

§Safety

The lifetime bounds on the items waited for ensure that these items live at least as long as the work queue. Practically, this can only be satisfied by using something with ‘static’ lifetime, or embedding the value in the Future itself.

With the Zephyr executor, the Context is embedded within a WakeInfo struct, which this makes use of. If a different executor were to be used, these calls would result in undefined behavior.

This could be checked at runtime, but it would have runtime cost.

Required Methods§

Source

fn add_semaphore<'a>( &'a mut self, sem: &'a Semaphore, timeout: impl Into<Timeout>, )

Indicate the work should next be scheduled based on a semaphore being available for “take”.

The work will be scheduled either when the given semaphore becomes available to ‘take’, or after the timeout.

Source

fn add_signal<'a>(&'a mut self, signal: &'a Signal, timeout: impl Into<Timeout>)

Indicate that the work should be scheduled after receiving the given Signal, or the timeout occurs.

Source

fn add_queue<'a>(&'a mut self, queue: &'a Queue, timeout: impl Into<Timeout>)

Indicate that the work should be scheduled when the given Queue has data available to recv, or the timeout occurs.

Source

fn add_timeout(&mut self, timeout: impl Into<Timeout>)

Indicate that the work should just be scheduled after the given timeout.

Note that this only works if none of the other wake methods are called, as those also set the timeout.

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.

Implementations on Foreign Types§

Source§

impl<'b> ContextExt for Context<'b>

Implementation of ContextExt for the Rust Context type.

Source§

fn add_semaphore<'a>( &'a mut self, sem: &'a Semaphore, timeout: impl Into<Timeout>, )

Source§

fn add_signal<'a>(&'a mut self, signal: &'a Signal, timeout: impl Into<Timeout>)

Source§

fn add_queue<'a>(&'a mut self, queue: &'a Queue, timeout: impl Into<Timeout>)

Source§

fn add_timeout(&mut self, timeout: impl Into<Timeout>)

Implementors§