Well-known that, the confd running as a separate process and uses IPC sockets to communicate with other applications. Here, I would like to run the confd as a thread along with the other running applications instead running as a separate process.
If the above is feasible, please guide how to proceed with this.
If not, then please specify the reasons and dis-advantages over this.
Note: The idea is to reduce the IPC socket communications between CDB and applications, since both will be running in two different processes.
Unfortunately that is not possible. ConfD is it’s own image and can’t be invoked from a thread in another process. It is of course possible to exec() the ConfD image from a thread in your process but that’s not what you want, the ConfD image would replace the old image, all your code/state would be gone and only ConfD would be eft.
The reason we run ConfD and clients in different processes is to protect ConfD from errors in clients (and clients from errors in ConfD). The cost of IPC is the price you have to pay.
Your application will run as a separate process and use IPC sockets to communicate with ConfD if you make use of the C, Java or Python based API through the libconfd library
To run your application with the same process as ConfD, i.e. running application code inside ConfD you need to write your code in Erlang and use the econfd API.
See ConfD UG “Running application code inside ConfD” and the examples under
To reduce the number of socket usage, we thought to have thread. But as per the understanding it’s possibly done only with Erlang.
Is any other possible way to have communication between confd and application without using sockets?
Or will you be able to provide cdb as a shared memory to directly accessing it.
Unless you implement your application in Erlang, you will not get away from using an IPC mechanism (e.g. a context switch) for communicating between your application and ConfD. You can however use a different IPC mechanism than TCP for the client library connections if you wish.
For the requirements that must be fulfilled by such an IPC mechanism, see chapter “Using a different IPC mechanism” in the ConfD UG.
A couple of example implementations of alternative IPC mechanisms can be found under the $CONFD_DIR/src/confd/ipc_drv directory.