►Ciox::popo::BasePort | This class is the base for all ports. it is constructed from a member pointer and is only movable. only movable rational: a port has only one member, a pointer to its data. if a port is copied then both ports would work on the same data even though these are two independent copies. this would case a weird shared state, race conditions and so on |
Ciox::popo::ApplicationPort | |
Ciox::popo::ClientPortRouDi | The ClientPortRouDi provides the API for accessing a client port from the RouDi middleware daemon side. The client port is divided in the three parts ClientPortData, ClientPortRouDi and ClientPortUser. The ClientPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between clients and servers ports can be established |
Ciox::popo::ClientPortUser | The ClientPortUser provides the API for accessing a client port from the user side. The client port is divided in the three parts ClientPortData, ClientPortRouDi and ClientPortUser. The ClientPortUser uses the functionality of a ChunkSender and ChunReceiver for sending requests and receiving responses. Additionally it provides the connect / disconnect API which controls whether the client port shall connect to the server |
Ciox::popo::InterfacePort | |
Ciox::popo::PublisherPortRouDi | The PublisherPortRouDi provides the API for accessing a publisher port from the RouDi middleware daemon side. The publisher port is divided in the three parts PublisherPortData, PublisherPortRouDi and PublisherPortUser. The PublisherPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between publisher and subscriber ports can be established |
Ciox::popo::PublisherPortUser | The PublisherPortUser provides the API for accessing a publisher port from the user side. The publisher port is divided in the three parts PublisherPortData, PublisherPortRouDi and PublisherPortUser. The PublisherPortUser uses the functionality of a ChunkSender for sending shared memory chunks. Additionally it provides the offer / stopOffer API which controls whether the publisher port is discoverable for subscriber ports |
Ciox::popo::ServerPortRouDi | The ServerPortRouDi provides the API for accessing a server port from the RouDi middleware daemon side. The server port is divided in the three parts ServerPortData, ServerPortRouDi and ServerPortUser. The ServerPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between clients and servers ports can be established |
Ciox::popo::ServerPortUser | The ServerPortUser provides the API for accessing a server port from the user side. The server port is divided in the three parts ServerPortData, ServerPortRouDi and ServerPortUser. The ServerPortUser uses the functionality of a ChunkSender and ChunReceiver for receiving requests and sending responses. Additionally it provides the offer / stopOffer API which controls whether the server is discoverable for client ports |
►Ciox::popo::SubscriberPortRouDi | The SubscriberPortRouDi provides the API for accessing a subscriber port from the RouDi middleware daemon side. The subscriber port is divided in the sevaral parts like SubscriberPortData, SubscriberPortRouDi and SubscriberPortUser. The SubscriberPortRouDi provides service discovery functionality that is based on CaPro messages. With this API the dynamic connections between publisher and subscriber ports can be established |
Ciox::popo::SubscriberPortMultiProducer | The SubscriberPortMultiProducer is the implementation of the SubscriberPortRouDi for a setup where subscribers can have multiple matching publishers. I.e. a n:m pub/sub deployment. The handling of CaPro messages is different for 1:m and n:m deployment |
Ciox::popo::SubscriberPortSingleProducer | The SubscriberPortSingleProducer is the implementation of the SubscriberPortRouDi for a setup where subscriber is allowed to have only one matching publisher. I.e. a 1:m pub/sub deployment. The handling of CaPro messages is different for 1:m and n:m deployment |
Ciox::popo::SubscriberPortUser | The SubscriberPortUser provides the API for accessing a subscriber port from the user side. The subscriber port is divided in the parts SubscriberPortData, SubscriberPortUser and different classes for RouDi side access. The SubscriberPortUser uses the functionality of a ChunkReceiver for receiving shared memory chunks. Additionally it provides the subscribe / unsubscribe API which controls whether the subscriber ports shall try to subscribe to matching publisher ports |
►Ciox::popo::BasePortData | Defines different base port data |
Ciox::popo::ApplicationPortData | |
Ciox::popo::ClientPortData | |
Ciox::popo::InterfacePortData | |
Ciox::popo::PublisherPortData | |
Ciox::popo::ServerPortData | |
Ciox::popo::SubscriberPortData | |
►Ciox::popo::BasePublisher< port_t > | The BasePublisher class contains the common implementation for the different publisher specializations |
Ciox::popo::PublisherImpl< T, H, BasePublisher_t > | |
Ciox::popo::UntypedPublisherImpl< BasePublisher_t > | |
►Ciox::popo::BaseSubscriber< port_t > | Base class for all types of subscriber |
Ciox::popo::SubscriberImpl< T, H, BaseSubscriber_t > | |
Ciox::popo::UntypedSubscriberImpl< BaseSubscriber_t > | |
Ciox::capro::CaproMessage | C'tors for CaPro messages |
Ciox::gw::Channel< IceoryxTerminal, ExternalTerminal > | A data structure representing a channel between Iceoryx and an external system |
Ciox::popo::ChunkDistributor< ChunkDistributorDataType > | The ChunkDistributor is the low layer building block to send SharedChunks to a dynamic number of ChunkQueus. Together with the ChunkQueuePusher, the ChunkDistributor builds the infrastructure to exchange memory chunks between different data producers and consumers that could be located in different processes. Besides a modifiable container of ChunkQueues to which a SharedChunk can be deliverd, it holds a configurable history of last sent chunks. This allows to provide a newly added queue a number of last chunks to start from. This is needed for functionality known as latched topic in ROS or field in ara::com. A ChunkDistributor is used to build elements of higher abstraction layers that also do memory managemet and provide an API towards the real user |
►Ciox::popo::ChunkDistributor< ChunkSenderDataType::ChunkDistributorData_t > | |
Ciox::popo::ChunkSender< ChunkSenderData< MAX_CHUNKS_ALLOCATED_PER_PUBLISHER_SIMULTANEOUSLY, ChunkDistributorData_t > > | |
Ciox::popo::ChunkSender< ChunkSenderData< MAX_REQUESTS_ALLOCATED_SIMULTANEOUSLY, ClientChunkDistributorData_t > > | |
Ciox::popo::ChunkSender< ChunkSenderData< MAX_RESPONSES_ALLOCATED_SIMULTANEOUSLY, ServerChunkDistributorData_t > > | |
Ciox::popo::ChunkSender< ChunkSenderDataType > | The ChunkSender is a building block of the shared memory communication infrastructure. It extends the functionality of a ChunkDistributor with the abililty to allocate and free memory chunks. For getting chunks of memory the MemoryManger is used. Together with the ChunkReceiver, they are the next abstraction layer on top of ChunkDistributor and ChunkQueuePopper. The ChunkSender holds the ownership of the SharedChunks and does a bookkeeping which chunks are currently passed to the user side |
►CChunkDistributorData_t | |
Ciox::popo::ChunkSenderData< MAX_CHUNKS_ALLOCATED_PER_PUBLISHER_SIMULTANEOUSLY, ChunkDistributorData_t > | |
►CChunkDistributorDataType | |
Ciox::popo::ChunkSenderData< MaxChunksAllocatedSimultaneously, ChunkDistributorDataType > | |
Ciox::mepoo::ChunkHeader | |
Ciox::mepoo::ChunkManagement | |
►CChunkQueueData_t | |
Ciox::popo::ChunkReceiverData< MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY, ChunkQueueData_t > | |
►CChunkQueueDataType | |
Ciox::popo::ChunkReceiverData< MaxChunksHeldSimultaneously, ChunkQueueDataType > | |
Ciox::popo::ChunkQueuePopper< ChunkQueueDataType > | The ChunkQueuePopper is the low layer building block to receive SharedChunks. It follows a first-in-first-out principle. Together with the ChunkDistributor and the ChunkQueuePusher, the ChunkQueuePopper builds the infrastructure to exchange memory chunks between different data producers and consumers that could be located in different processes. A ChunkQueuePopper is used to build elements of higher abstraction layers that also do memory managemet and provide an API towards the real user |
►Ciox::popo::ChunkQueuePopper< ChunkReceiverDataType::ChunkQueueData_t > | |
Ciox::popo::ChunkReceiver< ChunkReceiverData< MAX_REQUESTS_PROCESSED_SIMULTANEOUSLY, ServerChunkQueueData_t > > | |
Ciox::popo::ChunkReceiver< ChunkReceiverData< MAX_RESPONSES_PROCESSED_SIMULTANEOUSLY, ClientChunkQueueData_t > > | |
Ciox::popo::ChunkReceiver< ChunkReceiverData< MAX_CHUNKS_HELD_PER_SUBSCRIBER_SIMULTANEOUSLY, ChunkQueueData_t > > | |
Ciox::popo::ChunkReceiver< ChunkReceiverDataType > | The ChunkReceiver is a building block of the shared memory communication infrastructure. It extends the functionality of a ChunkQueuePopper with the abililty to pass chunks to the user side (user process). Together with the ChunkSender, they are the next abstraction layer on top of ChunkDistributor and ChunkQueuePopper. The ChunkRceiver holds the ownership of the SharedChunks and does a bookkeeping which chunks are currently passed to the user side |
Ciox::popo::ChunkQueuePusher< ChunkQueueDataType > | The ChunkQueuePusher is the low layer building block to push SharedChunks in a chunk queue. Together with the ChunkDistributor and ChunkQueuePopper the ChunkQueuePusher builds the infrastructure to exchange memory chunks between different data producers and consumers that could be located in different processes. A ChunkQueuePusher is the part of the chunk queue that is knwon by the ChunkDistributor |
Ciox::mepoo::ChunkSettings | |
Ciox::capro::ServiceDescription::ClassHash | |
Ciox::popo::ClientChunkDistributorConfig | |
Ciox::popo::ClientChunkQueueConfig | |
Ciox::config::CmdLineArgs_t | |
►Ciox::config::CmdLineParser | |
Ciox::config::CmdLineParserConfigFileOption | |
Ciox::popo::ConditionListener | ConditionListener allows one to wait using a shared memory condition variable |
Ciox::popo::ConditionNotifier | ConditionNotifier can notifiy waiting threads and processes using a shared memory condition variable |
Ciox::popo::ConditionVariableData | |
►CConfigParts | |
Ciox::Config< mepoo::SegmentConfig, config::RouDiConfig > | |
Ciox::Config< ConfigParts > | |
►CDesignPattern::Creation | |
Ciox::mepoo::SharedPointer< T > | DesignPattern::Creation offers us a create method which forwards the arguments to the constructor. Use this class like in the code example below |
Ciox::DefaultChunkDistributorConfig | |
Ciox::DefaultChunkQueueConfig | |
Ciox::roudi::DefaultRouDiMemory | |
Ciox::mepoo::MePooConfig::Entry | |
Ciox::popo::EventBasedTrigger_t | |
Ciox::popo::EventCallback< OriginType, ContextDataType > | |
Ciox::roudi::FixedPositionContainer< T, Capacity > | Workaround container until we have a fixed list with the needed functionality |
Ciox::roudi::FixedPositionContainer< iox::popo::ApplicationPortData, MAX_PROCESS_NUMBER > | |
Ciox::roudi::FixedPositionContainer< iox::popo::ConditionVariableData, MAX_NUMBER_OF_CONDITION_VARIABLES > | |
Ciox::roudi::FixedPositionContainer< iox::popo::InterfacePortData, MAX_INTERFACE_NUMBER > | |
Ciox::roudi::FixedPositionContainer< iox::popo::PublisherPortData, MAX_PUBLISHERS > | |
Ciox::roudi::FixedPositionContainer< iox::popo::SubscriberPortData, MAX_SUBSCRIBERS > | |
Ciox::roudi::FixedPositionContainer< iox::runtime::NodeData, MAX_NODE_NUMBER > | |
Ciox::roudi::FixedSizeContainer< T, capacity > | |
Ciox::roudi::FixedSizeContainer< ConnectionInfo, MAX_SUBSCRIBERS > | |
Ciox::roudi::FixedSizeContainer< PublisherInfo, MAX_PUBLISHERS > | |
►Ciox::gw::GatewayBase | Generic gateway for communication events |
Ciox::gw::GatewayGeneric< channel_t, gateway_t > | A reference generic gateway implementation |
Ciox::config::GatewayConfig | Generic configuration for gateways |
Ciox::gw::GatewayDiscovery< Impl_T > | Discover the gateway |
Ciox::roudi::IceOryxRouDiComponents | |
Ciox::roudi::ServiceRegistry::instance_t | |
Ciox::popo::InvalidId_t | Struct to signal the constructor to create an invalid id |
►Ciox::runtime::IpcInterfaceBase | Base-Class should never be used by the end-user. Handles the common properties and methods for the childs. The handling of the IPC channels must be done by the children |
Ciox::runtime::IpcInterfaceCreator | Class for creating and handling a IPC channel |
Ciox::runtime::IpcInterfaceUser | Class for using a IPC channel |
Ciox::runtime::IpcMessage | |
Ciox::runtime::IpcRuntimeInterface | |
Ciox::popo::Listener | The Listener is a class which reacts to registered events by executing a corresponding callback concurrently. This is achieved via an encapsulated thread inside this class |
►CLockingPolicy | |
►Ciox::popo::ChunkDistributorData< ChunkDistributorDataProperties, LockingPolicy, ChunkQueuePusherType > | |
Ciox::popo::ChunkSenderData< MAX_RESPONSES_ALLOCATED_SIMULTANEOUSLY, ServerChunkDistributorData_t > | |
Ciox::popo::ChunkSenderData< MAX_REQUESTS_ALLOCATED_SIMULTANEOUSLY, ClientChunkDistributorData_t > | |
►Ciox::popo::ChunkQueueData< ChunkQueueDataProperties, LockingPolicy > | |
Ciox::popo::ChunkReceiverData< MAX_RESPONSES_PROCESSED_SIMULTANEOUSLY, ClientChunkQueueData_t > | |
Ciox::popo::ChunkReceiverData< MAX_REQUESTS_PROCESSED_SIMULTANEOUSLY, ServerChunkQueueData_t > | |
Ciox::config::LoggingComponent | |
Ciox::LoggingComponent | |
►Ciox::roudi::MemoryBlock | The MemoryBlock is a container for general purpose memory. It is used to request some memory from a MemoryProvider, which can be POSIX SHM, the stack or something completely different. To be able to use the container, some functions need to be implemented. For most use cases the GenericMemoryBlock can be used, which is a templated class and implements the most common case |
Ciox::roudi::GenericMemoryBlock< T > | The GenericMemoryBlock is an implementation of a MemoryBlock for a common use case |
Ciox::roudi::MemPoolCollectionMemoryBlock | The MemPoolCollectionMemoryBlock is an implementation of a MemoryBlock for a MemPool MemoryManager |
Ciox::roudi::MemPoolSegmentManagerMemoryBlock | |
Ciox::roudi::PortPoolMemoryBlock | |
Ciox::mepoo::MemoryInfo | Stores properties of the memory to be used when we distinguish between different types of memory on e.g. different devices with different characteristics |
Ciox::mepoo::MemoryManager | |
►Ciox::roudi::MemoryProvider | This class creates memory which is requested by the MemoryBlocks. Once the memory is available, this is announced to the blocks, so that they can consume the memory for their needs. When the Memory is release, the blocks will also called to handle this appropriately, e.g. calling the destructor of the underlying type. This class is an interface with some default behavior and needs an implementation for real memory supply, e.g. a PosixShmMemoryProvider |
Ciox::roudi::PosixShmMemoryProvider | Creates the shared memory based on a provided configuration |
Ciox::mepoo::MemPool | |
Ciox::mepoo::MemPoolInfo | |
Ciox::roudi::MemPoolInfo | Struct for the storage of mempool usage information. This data container is used by the introstpection::MemPoolInfoContainer array to store information on all available memmpools |
Ciox::roudi::MemPoolIntrospection< MemoryManager, SegmentManager, PublisherPort > | This class handles the mempool intropection for RouDi. It is recommended to use the MemPoolIntrospectionType alias which sets the intended template parameters required for the actual introspection. The class sends snapshots of the mempool usage to the introspection client if subscribed |
Ciox::roudi::MemPoolIntrospection< mepoo::MemoryManager, mepoo::SegmentManager<>, PublisherPortUserType > | |
Ciox::roudi::MemPoolIntrospectionInfo | Topic for the mempool introspection that a user can subscribe to |
Ciox::mepoo::MePooConfig | |
Ciox::mepoo::MePooSegment< SharedMemoryObjectType, MemoryManagerType > | |
►Ccxx::NewType | |
Ciox::popo::TypedUniqueId< popo::BasePortData > | |
Ciox::popo::TypedUniqueId< T > | Unique ID depending on a type. If you would like to assign different types consistent unique ids use this class. Every types gets its own distinct set of ids starting with 0. If the types are the same the ids are the same |
Ciox::runtime::Node | Class which represents a node |
Ciox::runtime::NodeData | Struct which contains all the members of an object of type Node |
Ciox::runtime::NodeProperty | Helper struct which is convertable to string and constructable from a string which is required to send the createNode request over the IPC channel |
Ciox::popo::NotificationAttorney | Class which allows accessing private methods to friends of NotificationAttorney. Used for example by the WaitSet. Implements the Client-Attorney Pattern |
Ciox::popo::NotificationCallback< OriginType, ContextDataType > | Struct describes a callback with a user defined type which can be attached to a WaitSet or a Listener |
Ciox::popo::NotificationCallback< OriginType, internal::NoType_t > | Struct describes a callback which can be attached to a WaitSet or a Listener |
Ciox::popo::NotificationInfo | NotificationInfo holds the state of a trigger like the pointer to the triggerOrigin, the notification id and the callback |
Ciox::popo::internal::NoType_t | |
Ciox::mepoo::NoUserHeader | Helper struct to use as default template parameter when no user-header is used |
Ciox::helper::Optimize< ConfigParts > | |
Ciox::helper::Optimize< FinalArg > | |
Ciox::helper::Optimize< FirstArg, RemainderArgs... > | |
Ciox::runtime::PortConfigInfo | Stores information necessary to create the right type of port on RouDi side. Different types of ports are required if e.g. different types of shared memory are used (e.g. on GPU) |
►Ciox::roudi::PortData | Container for common port data which is related to the subscriber port as well as the publisher port |
Ciox::roudi::PublisherPortData | Container for publisher port introspection data |
Ciox::roudi::PortIntrospection< PublisherPort, SubscriberPort > | This class handles the port introspection for RouDi. It is recommended to use the PortIntrospectionType alias which sets the intended template parameter required for the actual introspection. The class manages a thread that periodically updates a field with port introspection data to which clients may subscribe |
Ciox::roudi::PortIntrospection< PublisherPortUserType, SubscriberPortUserType > | |
Ciox::roudi::PortIntrospectionFieldTopic | Topic for the port introspection that a user can subscribe to |
Ciox::roudi::PortManager | |
Ciox::roudi::PortPool | |
Ciox::roudi::PortPoolData | |
Ciox::roudi::PortThroughputData | |
Ciox::roudi::PortThroughputIntrospectionFieldTopic | Topic for the port throughput that a user can subscribe to |
►Ciox::runtime::PoshRuntime | The runtime that is needed for each application to communicate with the RouDi daemon |
Ciox::runtime::PoshRuntimeSingleProcess | |
Ciox::roudi::Process | |
Ciox::roudi::ProcessIntrospection< PublisherPort > | This class handles the process intropection for RouDi. It is recommended to use the ProcessIntrospectionType alias which sets the intended template parameter. The class tracks the adding and removal of processes and sends it to the introspection client if subscribed |
Ciox::roudi::ProcessIntrospection< PublisherPortUserType > | |
Ciox::roudi::ProcessIntrospectionData | |
Ciox::roudi::ProcessIntrospectionFieldTopic | Topic for the process introspection that a user can subscribe to |
►Ciox::roudi::ProcessManagerInterface | |
Ciox::roudi::ProcessManager | |
Ciox::popo::PublisherInterface< T, H > | The PublisherInterface class defines the publisher interface used by the Sample class to make it generic. This allows any publisher specialization to be stored as a reference by the Sample class. It is also needed to avoid circular dependencies between Sample and Publisher |
►Ciox::popo::PublisherInterface< T, mepoo::NoUserHeader > | |
Ciox::popo::PublisherImpl< T, H, BasePublisher_t > | |
Ciox::popo::PublisherOptions | This struct is used to configure the publisher |
Ciox::roudi::RouDi | |
►Ciox::roudi::RouDiApp | Base class for RouDi daemons |
Ciox::roudi::IceOryxRouDiApp | |
Ciox::config::RouDiConfig | |
►Ciox::roudi::RouDiConfigFileProvider | Base class for a config file provider |
Ciox::config::TomlRouDiConfigFileProvider | |
►Ciox::roudi::RouDiMemoryInterface | |
Ciox::roudi::IceOryxRouDiMemoryManager | |
Ciox::roudi::RouDiMemoryManager | |
Ciox::roudi::RouDi::RoudiStartupParameters | |
►Ciox::popo::RPCBaseHeader | |
Ciox::popo::RequestHeader | |
Ciox::popo::ResponseHeader | |
Ciox::popo::Sample< T, H > | The Sample class is a mutable abstraction over types which are written to loaned shared memory. These samples are publishable to the iceoryx system |
Ciox::popo::SampleDeleter< Port > | The SampleDeleter struct is a custom deleter in functor form which releases loans to a sample's underlying memory chunk via the corresponding port.. Each port should create its own instance of this deleter struct |
Ciox::popo::SampleDeleter< PortType > | |
Ciox::popo::SampleDeleter< typename BasePublisher_t::PortType > | |
Ciox::popo::internal::SamplePrivateData< T, H > | Helper struct for sample |
Ciox::popo::internal::SamplePrivateData< const T, H > | Specialization of helper struct for sample for const T |
Ciox::popo::internal::SamplePrivateData< T, cxx::add_const_conditionally_t< mepoo::NoUserHeader, T > > | |
Ciox::mepoo::SegmentConfig | |
Ciox::mepoo::SegmentConfig::SegmentEntry | |
Ciox::mepoo::SegmentManager< SegmentType > | |
Ciox::mepoo::SegmentManager< SegmentType >::SegmentMapping | |
Ciox::mepoo::SegmentManager< SegmentType >::SegmentUserInformation | |
Ciox::popo::ServerChunkDistributorConfig | |
Ciox::popo::ServerChunkQueueConfig | |
Ciox::capro::ServiceDescription | Class for the identification of a communication event including information on the service, the service instance and the event id. In order to support different communication protocols, two types of members exist: integer and string identifiers. If string IDs are used, the integers are initialized to an invalid number. A class object can be serialized/deserialized, so it is possible to send the information e.g. over a IPC channel |
Ciox::config::GatewayConfig::ServiceEntry | |
Ciox::roudi::ServiceRegistry | |
Ciox::helper::SetDefaults< ConfigParts > | |
Ciox::helper::SetDefaults< FinalArg > | |
Ciox::helper::SetDefaults< FirstArg, RemainderArgs... > | |
Ciox::mepoo::SharedChunk | WARNING: SharedChunk is not thread safe! Don't share SharedChunk objects between threads! Use for each thread a separate copy |
Ciox::runtime::SharedMemoryUser | Shared memory setup for the management segment user side |
Ciox::mepoo::ShmSafeUnmanagedChunk | This class to safely store a chunk in shared memory. To be able to do so, torn writes/reads need to prevented, since they create Frankenstein objects. Therefore, the class must not be larger than 64 bits and trivially copy-able in case an application dies while writing this and RouDi needs to clean up |
Ciox::popo::SingleThreadedPolicy | |
Ciox::popo::StateBasedTrigger_t | |
Ciox::popo::SubscriberOptions | This struct is used to configure the subscriber |
Ciox::roudi::SubscriberPortChangingData | |
Ciox::roudi::SubscriberPortChangingIntrospectionFieldTopic | |
Ciox::popo::ThreadSafePolicy | |
Ciox::config::TomlGatewayConfigParser | Methods for parsing gateway configs from toml text files |
Ciox::popo::internal::TranslateAndCallTypelessCallback< T, ContextDataType > | |
Ciox::popo::internal::TranslateAndCallTypelessCallback< T, NoType_t > | |
Ciox::popo::Trigger | Usually managed by a factory class like a WaitSet and acquired by classes which would like to signal a notification. Multiple Trigger can share a common ConditionVariableData pointer so that multiple Trigger can signal a single instance |
Ciox::popo::TriggerHandle | TriggerHandle is threadsafe without restrictions in a single process. Not qualified for inter process usage. The TriggerHandle is generated by a Notifyable like the WaitSet and handed out to the user when they acquire a trigger. The TriggerHandle corresponds with an internal Trigger and is used to signal an event via the trigger method. When it goes out of scope it cleans up the corresponding trigger in the Notifyable |
Ciox::mepoo::TypedMemPool< T > | |
Ciox::popo::UsedChunkList< Capacity > | This class is used to keep track of the chunks currently in use by the application. In case the application terminates while holding chunks, this list is used by RouDi to retain ownership of the chunks and prevent a chunk leak. In order to always be able to access the used chunks, neither a vector or list can be used, because these container could be corrupted when the application dies in the wrong moment. To be able to do the cleanup, RouDi needs to be able to access the list with the used chunk under all circumstances. This is achieved by storing the ChunkManagement pointer in an array which can always be accessed. Additionally, the type stored is this array must be less or equal to 64 bit in order to write it within one clock cycle to prevent torn writes, which would corrupt the list and could potentially crash RouDi |
Ciox::popo::UsedChunkList< MAX_CHUNKS_IN_USE > | |
Ciox::popo::UsedChunkList< MaxChunksAllocatedSimultaneously > | |
Ciox::popo::UserTrigger | An event based trigger which can be used by the application developer directly. If you would like to trigger a WaitSet/Listener through an event of your class you should use the Trigger class |
Ciox::popo::Void | |
Ciox::popo::WaitSet< Capacity > | Logical disjunction of a certain number of Triggers |