Thread: IPC communication between parent and child

Hello I am working on a cli/server project, where when a client connects to the server, the server spawns a new thread to handle the client. So for each client a new thread is spawned.

This is all fine but I need to be able to communicate between the main server and the threads that are spawned by it. I also want to be able to communicate between clients via the server.

So here are examples to illustrate:

Cli A->Server->thread A
Cli B->Server->thread B
Cli C->Server->thread C

so now I will need to have threadA directly communicate with Server thread for reporting purposes.

I also would like to have communication between clients for example:
Cli A->Cli C
Now I probably need to setup a connection similar to this:
Cli A->thread A->Server->thread C->Cli C

I know I'll have to use IPC for this but I am not sure which method is best since this is new subject for me.
If anyone can give me ideas on this I would appreciate it.

Do you have separate processes, or are you using pthreads?

Originally Posted by Durango2011

This is all fine but I need to be able to communicate between the main server and the threads that are spawned by it.

Since all threads within the process share the same memory, all you need is some form of locking (rwlock, mutex, semaphore) or atomic operations, to make sure each thread sees and modifies consistent values.

If, however, you intended to write processes instead of threads -- meaning you use fork() or posix_spawn() instead of pthread_create() to create your workers, then you have several options. The two most typical ones are a shared anonymous memory map to act as a scoreboard between itself and all workers (within the scoreboard, you can use same approach as with threads), and pipes or socket pairs. The shared memory map is especially useful if the same message is relayed to multiple clients. Unix domain socket pairs have certain features, like credential passing, which is sometimes very useful, especially if the worker processes are not forked copies of the original process, but separate applications running under different system accounts.

Although it obviously depends on the communications patterns, I do believe the shared memory approach fits your needs best. I'd need more information on communication patterns (whether you have one client to all other clients -type messages, message length limits, messages between clients directly, and so on) and whether you're using threads or processes, to suggest any details.