pub struct WatcherSynchronousProxy { /* private fields */ }
Implementations§
Source§impl WatcherSynchronousProxy
impl WatcherSynchronousProxy
pub fn new(channel: Channel) -> Self
pub fn into_channel(self) -> Channel
Sourcepub fn wait_for_event(
&self,
deadline: MonotonicInstant,
) -> Result<WatcherEvent, Error>
pub fn wait_for_event( &self, deadline: MonotonicInstant, ) -> Result<WatcherEvent, Error>
Waits until an event arrives and returns it. It is safe for other threads to make concurrent requests while waiting for an event.
Sourcepub fn on_level_changed(
&self,
level: Level,
___deadline: MonotonicInstant,
) -> Result<(), Error>
pub fn on_level_changed( &self, level: Level, ___deadline: MonotonicInstant, ) -> Result<(), Error>
Sent to the registered client when the memory pressure level changes.
level
: indicates the current memory pressure level.
Will also be invoked on initial connection via RegisterWatcher
, so that a newly
registered client can discover the current memory pressure level.
The watcher must immediately reply with a message to acknowledge that it has received the level change notification, and has initiated required actions as a result. It may then continue to reclaim memory asynchronously after sending the acknowledgement.
Some helpful guidelines for clients:
-
The watcher will be notified of new pressure level changes only after a reply corresponding to the previous message has been received by the provider. If multiple level transitions occur during that time, the watcher will be notified of the latest pressure level.
-
The level changes are edge-triggered, and clients are expected to maintain local state to track the current pressure level, if required. For example, a job might be notified of a CRITICAL level and drop all its caches as a result. Some time after this, it might want to trigger an activity that causes a fair amount of memory to be allocated. At this point, the job is expected to remember that the last pressure level it saw was CRITICAL, and refrain from triggering the memory-intensive activity.
-
As a performance optimization, the provider may decide to skip sending messages for some pressure level changes. For example, when oscillating across the NORMAL / WARNING boundary, it might not be worth notifying clients of every single transition. The provider might rate-limit messages in this case. On a similar note, the provider may decide to send repeated messages at the same pressure level, particularly CRITICAL, to indicate that further action needs to be taken.
Trait Implementations§
Source§impl Debug for WatcherSynchronousProxy
impl Debug for WatcherSynchronousProxy
Source§impl SynchronousProxy for WatcherSynchronousProxy
impl SynchronousProxy for WatcherSynchronousProxy
Source§type Proxy = WatcherProxy
type Proxy = WatcherProxy
Source§type Protocol = WatcherMarker
type Protocol = WatcherMarker
Proxy
controls.