In order to understand this part, one should be familiar with the control/worker socket concept in Data Providers: Information about this can be found in section 6.6.
libconfd supports multi-threaded as well as single threaded applications.
The choice to use multiple threads VS a single thread when integrating with ConfD depends on the operations your application needs to process during a callback from ConfD.
Data Providers (DP) are responsible for operational data that users need to read. ConfD provides a mechanism for DP application to register callbacks to fetch that data.
Action callbacks can also be registered for RPC ( or tail-f:action ) statements in the data model.
A need for multiple threads emerges from the fact that a callback might take a long time to complete. To unblock other user sessions, to be able to call the same callback, using threads can be the solution: A thread would be responsible for processing each callback in this case.
Another user case is that of a deadlock caused by an action callback.
An action callback can be trying to read operational data as well, using MAAPI. With a single thread, we will face a deadlock in this situation i which MAAPI won’t be able to proceed unless we return from the action…
A good example for this can be found in the $CONFD_DIR/examples.confd/9-c_threads folder.