views:

539

answers:

4

I've got a project that consists of two processes and I need to pass some data between them in a fast and efficent manner.

I'm aware that I could use sockets to do this using TCP, even though both processes will always exist on the same computer, however this does not seem to be a very efficient solution.

I see lots of information about using "pipes" on Linux. However I primarily want this for Windows and Linux (preferably via a cross platform library), ideally in a type safe, non-blocking manner.

Another important thing is I need to support multiple instances of the whole application (i.e. both processes), each with their own independent copy of the communication objects.

Also is there a cross platform way to spawn a new process?

+1  A: 

It may be overkill, but you could use the Apache Portable Runtime; here are the thread and process functions.

Doug Currie
+7  A: 

For IPC, Windows supports named pipes just like Linux does, except that the pipe names follow a different format, owing to the difference in path formats between the two operating systems. This is something that you could overcome with simple preprocessor defines. Both operating systems also support non-blocking IO on pipes and IO multiplexing with select().

Tyler McHenry
+11  A: 

Take a look at Boost.Interprocess

Boost.Interprocess simplifies the use of common interprocess communication and synchronization mechanisms and offers a wide range of them:

  • Shared memory.
  • Memory-mapped files.
  • Semaphores, mutexes, condition variables and upgradable mutex types to place them in shared memory and memory mapped files.
  • Named versions of those synchronization objects, similar to UNIX/Windows sem_open/CreateSemaphore API.
  • File locking.
  • Relative pointers.
  • Message queues.

Boost.Interprocess also offers higher-level interprocess mechanisms to allocate dynamically portions of a shared memory or a memory mapped file (in general, to allocate portions of a fixed size memory segment). Using these mechanisms, Boost.Interprocess offers useful tools to construct C++ objects, including STL-like containers, in shared memory and memory mapped files:

  • Dynamic creation of anonymous and named objects in a shared memory or memory mapped file.
  • STL-like containers compatible with shared memory/memory-mapped files.
  • STL-like allocators ready for shared memory/memory-mapped files implementing several memory allocation patterns (like pooling).

Boost.Interprocess has been tested in the following compilers/platforms:

  • Visual 7.1 Windows XP
  • Visual 8.0 Windows XP
  • GCC 4.1.1 MinGW
  • GCC 3.4.4 Cygwin
  • Intel 9.1 Windows XP
  • GCC 4.1.2 Linux
  • GCC 3.4.3 Solaris 11
  • GCC 4.0 MacOs 10.4.1
Kirill V. Lyadvinsky
boost::interprocess has a dummy implementation on windows which uses busy-waits for everything. I wouldn't recommend it myself.
bdonlan
+2  A: 

Plain old TCP should work fairly efficiently; as I understand it, modern OS's will detect when both ends of a TCP connection are located on the same machine, and will internally route that data through a fast, lightweight (pipe-like) mechanism rather than through the ordinary TCP stack.

So if you already have code that works over TCP, I say stick with that and avoid spending a lot of extra development time for not much payoff.

Jeremy Friesner
What OS does that what you said? Please share w/ me.
EffoStaff Effo
If Linux, I'm sure it not, because packets could be captured by tcpdump while 2 ends on the same machine.
EffoStaff Effo
My post is based mostly off a conversation I had with RobSeace at the Unix Sockets FAQ site, you can read it here: http://www.developerweb.net/forum/showthread.php?t=5154 In particular, this quote from Rob: "Yes, Unix domain sockets would be much more efficient, bypassing a lot of the kernel TCP/IP stack stuff that's not necessary with local IPC... (Though, if you use 127.0.0.1, most modern systems should optimize the loopback interface quite a bit, too...) "
Jeremy Friesner