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.
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.