Module reactive_messaging::prelude

source ·
Expand description

Re-exports of types useful for users of this crate

Re-exports

Macros

Structs

  • ConstConfig
    Implements something that could be called the “Zero-Cost Const Configuration Pattern”, that produces a usize whose goal is to be the only const parameter of a generic struct (avoiding the alternative of bloating it with several const params).
    When using the const “query functions” defined here in ifs, the compiler will have the opportunity to cancel out any unreachable code (zero-cost abstraction).
    Some commonly used combinations may be pre-defined in some enum variants, but you may always build unmapped possibilities through [Self::custom()].
    Usage examples:
  • GenericSocketClient
    Real definition & implementation for our Socket Client, full of generic parameters.
    Probably you want to instantiate this structure through the sugared macro new_socket_client!() instead. Generic Parameters:
  • GenericSocketServer
    Real definition & implementation for our Socket Server, full of generic parameters.
    Probably you want to instantiate this structure through the sugared macro new_socket_server!() instead. Generic Parameters:
  • Multi
    Multi is an event handler capable of having several “listeners” – all of which receives all events.
    With this struct, it is possible to:
  • MutinyStream
    Special Stream implementation to avoid using dynamic dispatching, so to allow the compiler to fully optimize the whole event consumption chain.
    The following paths are covered:
  • OgreArc
    Wrapper type for data providing an atomic reference counter for dropping control, similar to Arc, but allowing a custom allocator to be used – OgreAllocator. providing reference counting similar to Arc
  • OgreUnique
    Wrapper type for data that requires a custom Drop to be called (through an OgreAllocator). Similar to C++’s unique_ptr
  • Peer
    Represents a reactive channel connected to a remote peer, through which we’re able to send out “local messages” of type RetryableSenderImpl::LocalMessages.
    the Self::send() method honors whatever retrying config is specified in [RetryableSenderImpl::CONST_CONFIG]. IMPLEMENTATION NOTE: GAT traits (to reduce the number of generic parameters) couldn’t be used here – even after applying this compiler bug workaround https://github.com/rust-lang/rust/issues/102211#issuecomment-1513931928 – the “error: implementation of std::marker::Send is not general enough” bug kept on popping up in user provided closures that called other async functions.
  • SocketOptions
    Socket options for the local peer to be set when the connection is stablished
  • Uni
    Contains the producer-side Uni handle used to interact with the uni event – for closing the stream, requiring stats, …

Enums

  • Channels
    Specifies the channels (queues) from reactive-mutiny thay may be used to send/receive data.
    On different hardware, the performance characteristics may vary.
  • ConnectionEvent
    The internal events a reactive processor (for a server or client) shares with the user code.
    The user code may use those events to maintain a list of connected clients, be notified of stop/close/quit requests, init/de-init sessions, etc. Note that the Peer objects received in those events may be used, at any time, to send messages to the clients – like “Shutting down. Goodbye”. IMPLEMENTATION NOTE: GAT traits (to reduce the number of generic parameters) couldn’t be used here – even after applying this compiler bug workaround https://github.com/rust-lang/rust/issues/102211#issuecomment-1513931928 – the “error: implementation of std::marker::Send is not general enough” bug kept on popping up in user provided closures that called other async functions.
  • Instruments
    Honors the Zero-Cost Instrumentation Pattern for the [stream_executors]:
    Designed to be used as a const generic parameter for Structs, causes the conditional instrumentation code in client structs to be selectively compiled – see the implemented const methods for documentation of each available instrument.
  • RetryingStrategies
    Specifies how to behave when communication failures happen
  • SocketClient
    Represents a client built out of CONFIG (a u64 version of [ConstConfig], from which the other const generic parameters derive).
    Don’t instantiate this struct directly – use new_socket_client!() instead.
  • SocketServer
    Represents a server built out of CONFIG (a u64 version of [ConstConfig], from which the other const generic parameters derive).
    Don’t instantiate this struct directly – use new_socket_server!() instead.

Traits

  • ChannelCommon
    Defines common abstractions on how [Uni]s receives produced events and delivers them to Streams.
    Implementors should also implement one of ChannelProducer or [UniZeroCopyChannel]. NOTE: all async functions are out of the hot path, so the async_trait won’t impose performance penalties
  • ChannelConsumer
    Source of events for MutinyStream.
  • ChannelMulti
    Defines abstractions specific to [Uni] channels
  • ChannelProducer
    Defines how to send events (to a [Uni] or [Multi]).
  • ChannelUni
    Defines abstractions specific to [Uni] channels
  • FullDuplexMultiChannel
    A fully fledged Multi channel, that has both the producer and consumer parts Also, laverages generic programming by allowing simpler generic parameters:
  • FullDuplexUniChannel
    Defines a fully fledged Uni channel, that has both the producer and consumer parts Also, laverages generic programming by allowing simpler generic parameters:
  • GenericMulti
    This trait exists to allow simplifying generic declarations of concrete Multi types. See also [GenericUni].
    Usage:
  • GenericUni
    This trait exists to allow simplifying generic declarations of concrete Uni types. See also [GenericMulti].
    Usage:
  • OgreAllocator
    Dictates how data slots should be acquired and returned for future reuse.
    Two APIs are available:
  • ResponsiveMessages
    Adherents will, typically, also implement [ReactiveMessagingUnresponsiveSerializer].
    By upgrading your type with this trait, it is possible to build a “Responsive Processor”, where the returned Stream contains the messages to be sent as an answer to the remote peer.
    This trait, therefore, specifies (to the internal sender) how to handle special response cases, like “no answer” and “disconnection” messages.

Type Aliases