In certain scenarios, you may want full control over the internal threads created by your Connext DDS applications. For instance, in memory-constrained systems, applications may want to manage the resources required by internal Connext DDS threads. Also, you may want to use a different thread technology than the one Connext DDS incorporates by default (i.e., pthread on POSIX platforms).
Connext DDS can create the internal threads from the application layer via the abstract factory pattern. You can provide a Connext DDS application with a ThreadFactory implementation that DomainParticipants will use to create and delete all the threads.
The ThreadFactory interface exposes operations for creating and deleting threads. These operations are called on demand as DomainParticipants require new threads or need to delete existing ones.
The same ThreadFactory instance can be used by multiple DomainParticipants. To select which ThreadFactory to use, use the set_thread_factory() operation in the DomainParticipantFactory:
MyThreadFactory myThreadFactory; // Implements DDSThreadFactory retcode = DDSTheParticipantFactory->set_thread_factory(&myThreadFactory);
Then you can create DomainParticipants using any of the available APIs (i.e. create_participant(), create_participant_from_config(), etc). A DomainParticipant will use the ThreadFactory object that is set in the DomainParticipantFactory at the time it is created and throughout its entire lifecycle. If a new ThreadFactory is set, existing DomainParticipants will not be affected; they will still use the same ThreadFactory with which they were created.
This feature is only available for the C/C++ APIs. For further information, please see the API Reference HTML documentation.
© 2018 RTI