Chapter 81 User-Managed Threads

In certain scenarios, you may want full control over the internal threads created by your Connext applications. For instance, in memory-constrained systems, applications may want to manage the resources required by internal Connext threads. Also, you may want to use a different thread technology than the one Connext incorporates by default (i.e., pthread on POSIX platforms).

Connext can create the internal threads from the application layer via the abstract factory pattern. You can provide a Connext 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.