Inter-Process Communication Recommendation [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem a开发者_开发知识库nd what has been done so far to solve it.

Closed 9 years ago.

Improve this question

I'm searching for a light-weight, fast and easy way to handle Inter Process Communication between some programs on a Linux machine.

Currently, I'm thinking Named Pipe, because it's provided by the OS itself. Are there any caveats about the performance or usability?

Would Shared Memory be better?

I don't think I need a super-complex Framework.

Please point me in the right direction, thanks!

---

Update: I want to build a small program (daemon) that tells other programs (which it itself starts) to pause, report their status back, stop etc.

So the other program should be notified that a new command is waiting for it. A pipe is not ideal for that, is it?

---

As you have seen, you can use for inter process communication :

• Shared memory
• Named pipes
• TCP/UDP sockets (eventually local ones)

Shared memory has the advantage of performance, because you do not have any buffer when sending/receiving messages. But you have to synchronise your data exchanges whith another IPC. It can be IPC semaphores or ... named pipes or sockets.

When performance is not the main goal, I tend to prefer sockets as their use is simple and can be extended to inter computer communication.

The best way is to abstract your communication with a class that can use shared memory when the two processes are on the same computer and sockets if not. Then You have to choose between UDP and TCP ;-)

For synchro / buffer exchange, prefer TCP as it more reliable.

I do not use named pipes as I prefer socket for the possibility to use inter computer communicationand of course you can find a lot of portable socket libraries...

my2cents

EDIT:

For synchronisation, shared mem is perhaps not the best tool. In your case it can be used by sharing a small memory space, with a space for each process that wait for commands. You can either poll for any incomming command or use a shared semaphore. The fastest way is your processes waiting for named semaphores and reading a shared mem space for their commands/parameters. Using named pipes is surely simplier but not that fast. You surely do not need to be that fast ? Anyway abstract that in a class that models your exchange protocol and try the two ways :-)

---

Boost has a nice InterProcess library that is cross-platform and quite intuitive.

I have only toyed with it though, so there might be better alternatives out there.

However, if you don't really need shared memory, I would stick with a messaging approach. You'll avoid deadlocks and race conditions. The pipe principle is really great, and it even allows for lazy behaviors which may save you a lot of processing depending on the matter at hand!

---

A good choice is to use socketpair, very fast and efficient.

---

D-Bus is pretty useful and very stable to do ipc in the same host. http://www.freedesktop.org/wiki/Software/dbus

---

I'd use unix sockets, or some library which wraps them. Unix sockets are pretty easy to use.

On the other hand if you have fixed-size status information to report back, you could just have the child processes write it into a file (presumably it's small and you won't fsync it, so it won't generate significant IO workload).

---

Shared memory along with semaphores is the fastest and most transparent if you like to build software right from the primitives.

Named pipes are not too different from pipes and work well between a pair of processes and not a server and many clients.

If you like to build upon existing infrastructure, dBus is an option.

Socket communication is versatile and scales well if you wish to move your applications across hosts on a network.