The RECEIVER_POOL QosPolicy configures the internal Connext DDS thread used to process the data received from a transport. The Receive thread is described in detail in Receive Threads.
This QosPolicy contains the members in DDS_ReceiverPoolQoSPolicy.
|
Type |
Field Name |
Description |
|
struct DDS_ThreadSettings_t |
thread.mask thread.priority thread.stack_size hread.cpu_list thread.cpu_rotation |
Thread settings for the receive thread(s) used by Connext DDS to process data received from a transport. The values used for these settings are OS-dependent; see the RTI Connext DDS Core Libraries Platform Notes for details. |
|
DDS_Long |
buffer_size |
Size of the receive buffer in bytes. For the default and valid range, see the API Reference HTML documentation. buffer_size must always be at least as large as the maximum message_size_max of any installed non-zero-copy transport.1A “receive zero-copy transport” does not use the receive buffer. It just provide the transport buffer where data is received directly to the middleware. A transport is zero-copy if the properties_bitmap property in the DDS_Transport_Property_t is NDDS_TRANSPORT_PROPERTY_BIT_BUFFER_ALWAYS_LOANED. The only built-in transports that support zero-copy is the UDPv4 transport on VxWorks platforms and the Shared memory transport in all platforms. The buffer_size can be adjusted automatically by the middleware by configuring its value to DDS_LENGTH_AUTO (in C/C++) or ReceiverPoolQosPolicy.LENGTH_AUTO (in .NET and Java). When set to this AUTO default value, the effective value will automatically be set to the largest message_size_max of all installed transports, without needing any other configuration. Therefore you should not need to change this value. |
|
DDS_Long |
buffer_alignment |
Byte-alignment of the receive buffer. For the default and valid range, see the API Reference HTML documentation. |
This QosPolicy sets the thread properties, like priority level and stack size, for the threads used to receive and process data from transports. Connext DDS uses a separate receive thread per port per transport plugin. To force Connext DDS to use a separate thread to process the data for a DataReader, you should set a unique port for the TRANSPORT_UNICAST QosPolicy (DDS Extension) or TRANSPORT_MULTICAST QosPolicy (DDS Extension) for the DataReader.
Connext DDS creates at least one thread for every transport that is installed and enabled for use by the DomainParticipant for receiving data. These threads are used to process data DDS samples received for the participant’s DataReaders, as well as messages used by Connext DDS itself in support of the application discovery process discussed in Discovery.
The user application may configure Connext DDS to create many more threads for receiving data sent via multicast or even to dedicate a thread to process the DDS data samples of a single DataReader received on a particular transport. This QosPolicy is used in the creation of all receive threads.
When new data arrives on a transport, the receive thread may invoke the on_data_available() of the Listener callback of a DataReader. Thus, you may want to adjust the priority of the receive threads with respect to the other threads in the application as appropriate for the proper operation of the system.
This QosPolicy cannot be modified after the DomainParticipant is created.
It can be set differently on the publishing and subscribing sides.
Increasing the buffer_size will increase memory used by a receive thread.
Setting the thread parameters correctly on a real-time operating system is usually critical to the proper overall functionality of the applications on that system. Larger values for the thread.stack_size parameter will use up more memory.
© 2018 RTI