Struct ChunkReceiver 

pub struct ChunkReceiver { /* private fields */ }

A wrapper that allows receiving message chunks in real-time. Be mindful that, once one of these is created, all chunks that arrive for the message it tracks will be immediately sent to it, thereby preventing any calls to .get() on the Interface from accessing non-empty data.

Implementations

impl ChunkReceiver

pub fn termination_timeout_millis(self, millis: usize) -> Self

Sets the maximum number of milliseconds that this receiver could potentially wait for on a call to .recv()/.recv_raw() if the underlying wire terminates.

The default value is 10 milliseconds: higher values will mean more time between a wire termination and an error being returned, and lower values will mean more resource-intensive waiting for values when termination does not occur.

pub async fn recv_raw(&mut self) -> Result<Option<Vec<u8>>, Error>

Waits to receive the raw bytes of the next chunk.

If this finds that the underlying message’s completion lock has been poisoned (which would typically happen if the wire had been terminated), then it will return an error. Note that this does not necessarily mean that it cannot be polled again, as there may still be a chunk or two left to come through due to atomic operations and ordering. If the message is later completed, any poisons would be removed and this would calmly return Ok(None).

In order to continually check the completion lock to ensure it hasn’t been poisoned, this implements receiving through a timeout. If the timeout is reached, the completion lock is checked again, and then the timeout restarts. This means this performs more resource-intensive waiting than a traditional receiver call would, although this should not be material for most applications. (The default timeout is 10 milliseconds, which is thus the maximum time this would wait for after a wire had been terminated.)

pub async fn recv<T: DeserializeOwned>( &mut self, ) -> Result<Option<Result<T, Error>>, Error>

Waits to receive the next chunk, deserialising it into the given type. Generally, all chunks will be deserialised into the same type, however it is perfeclty possible, if there is a known type layout, to deserialise one chunk as one type and a different one as another, although this is not recommended except in highly deterministic systems.

The convoluted return type of this function indicates the following: 1. There could be a poisoned lock involved when we poll, so there might be an error with polling, 2. But if there isn’t, the sender might have been dropped (i.e. message is complete), 3. Even if there is a chunk, we might fail to deserialise it, 4. If all that works, you get T.