Inter-Process Communication Recommendation

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?

Answer 1

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!

Answer 2

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 :-)

Answer 3

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

Answer 4

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

Answer 5

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