1

I have the following problem, and I understand that I need to use either IPC via shared memory or network sockets.

I have one executable (meaning a separate .exe), compiled with VS2010, that gets the data from somewhere, and it should make that data available to the second executable.

boost::interprocess::managed_shared_memory managed_shm(
    boost::interprocess::open_or_create,
    "MyMemBlock",
    4000000);

The second executable is compiled with VS2012 and should receive that data (or fetch from memory) and process it.

// fails with a boost::interprocess::interprocess_exception
boost::interprocess::managed_shared_memory managed_shm(
    boost::interprocess::open_only,
    "MyMemBlock");

The whole thing needs to be as fast as possible. Compiling both executables with the same Visual Studio version is not an option, one codebase compiles only with VS2010, the other one only with VS2012/2013.

However, my first try with boost::interprocess didn't work (the second process throws a boost::interprocess::interprocess_exception), and I don't fully understand how exactly the memory gets shared, or more precise, how the shared memory information gets communicated from one process to the other. How does the first exe populate the information of the shared memory block? Does it only work for multiple processes inside one executable? Not multiple .exe's? Does it have to be the same boost DLL that is used by both executables? Is my only option IPC via Sockets?

Frerich Raabe
  • 90,689
  • 19
  • 115
  • 207
Ela782
  • 5,041
  • 5
  • 53
  • 66
  • You're entire problem description consists of the two words, "didn't work". (The most common program with shared memory, by the way, is having one process store an ordinary pointer in shared memory and then have the other process try to dereference it. It's easy to do this without realizing it. For example, you can't store a `std::string` in shared memory because it does this.) – David Schwartz Dec 12 '13 at 19:50
  • @DavidSchwartz I mentioned in the second code-block that this function throws. You had to scroll a lot to the right to see it though. I updated the question to make this clearer. My main question though is if this shared memory IPC can work with 2 different executables that are compiled with 2 different boost DLLs. Because my mind cannot imagine how the second process could possibly find the first process's memory. All examples I can find are using _one_ executable that spawns two different processes. – Ela782 Dec 12 '13 at 19:56
  • I think the different boost DLL's shouldn't matter, but the way your data is structured in the shared memory definitely would. You shouldn't try to share any binary data structures, but plain serializable data or primitive data types only. – πάντα ῥεῖ Dec 12 '13 at 20:04
  • I think they might matter. That is what I'd like to find out here. Above code works if run one line after each other in the same cpp file, but doesn't work if run in 2 different executables. I'm not even trying yet to share any data, I can't access the shared memory from the 2nd executable. – Ela782 Dec 12 '13 at 20:08
  • 1
    Do both applications have admin rights? If not, try that! – Till Dec 12 '13 at 20:11
  • 1
    Actually, I got it to work. Till, you made me thinking - I tried both with admin rights but it made no difference. But actually one app was using boost 1.53 and the other 1.55. I then tried 1.53 on both - boom, it worked. So my real question got kind of answered by myself by the fact that it works: Yes, IPC works not only across 2 processes in 1 executable, but also across 2 different executables that use different compilers, different libc's, different boost DLLs, BUT they have to use the same boost _version_! – Ela782 Dec 12 '13 at 20:35
  • Whoever feels they contributed most is free to formulate the answer, if nothing is here by tomorrow, I'll post it. Thanks! – Ela782 Dec 12 '13 at 20:35

2 Answers2

2

IPC works across two different executables. The two processes accessing the shared memory don't need to be compiled into the same executable. In fact, they can be compiled with different versions of visual studio and different boost DLL's. However, one has to use the same version of boost in both executables.

Quite interestingly, what is also not working, is running one executable in release-build and the other one in debug-build. I guess they allocate memory in a completely different way and can't share it.

Ela782
  • 5,041
  • 5
  • 53
  • 66
1

You can try native Windows IPC. There many you can google them. I recommend Memory-mapped files. Here also nice article from MS

This is for example scenario of Non-persisted memorymap file.

1. Process A creates the memory-mapped file and writes a value to it.

2. Process B opens the memory-mapped file and writes a value to it.

3. Process C opens the memory-mapped file and writes a value to it.

4. Process A reads and displays the values from the memory-mapped file.

5. After Process A is finished with the memory-mapped file, the file is 
   immediately reclaimed by garbage collection.

Taken from here

Boost also have implementation of memory-mapped files, it will use native lowlevel API according to compiling target platform. Sample code can be taken here

Boris Ivanov
  • 4,145
  • 1
  • 32
  • 40
  • Memory-mapped files indeed is a pretty easy solution. – Till Dec 12 '13 at 20:02
  • 1
    It kind of should be cross-platform. And I suspect this will have the same problem as my try with boost ipc: Can it work with 2 different executables that are compiled with 2 different library/libc DLLs? – Ela782 Dec 12 '13 at 20:04
  • It's is not cross platform. But you can try Boost ones http://www.boost.org/doc/libs/1_35_0/libs/iostreams/doc/classes/mapped_file.html – Boris Ivanov Dec 12 '13 at 20:23
  • 1
    Memory mapped files are fast and easy! I recommend them. – japreiss Dec 12 '13 at 20:27
  • Thank you all for your help. I got a bit misunderstood though: My question was never how to do IPC and what the different ways are. I am familiar with that. It was all about the 2 executables and different DLLs. But you gave me some nice links and hints nevertheless here, thanks! – Ela782 Dec 12 '13 at 20:37