5

I am currently looking at the documentation for Boost's interprocess library, and am trying to figure out what the difference is.

From all I can tell the only difference is the persistence (windows shared memory is released when the last process exits, managed_shm is released only when told so), are there other differences like speed or so that I am missing?

SinisterMJ
  • 3,425
  • 2
  • 33
  • 53
  • 2
    Platform compatibility? Something like `windows_shared_memory` seems very platform-specific. – Some programmer dude Sep 01 '17 at 09:29
  • Thats true, it is windows only, but there must be some advantage to use it over managed_shared_memory? – SinisterMJ Sep 01 '17 at 09:32
  • I would imagine it has exactly the capabilities of shared memory on the windows platform, rather than the common subset of capabilities that are available on all the platforms that boost::interprocess supports – Caleth Sep 01 '17 at 10:25
  • For me the advantage is it cleans itself up on process exit. That is what I wanted and I was in the middle of writing a really complicated system to do cleanup of old "sessions" that got killed when new sessions started up and it was a gross nightmare. Then I found the windows native version and just deleted that whole mess. If you need persistence then the other is what you want, but otherwise assuming you are windows only then go windows native to prevent leaks imo. – Greg Cobb Dec 22 '18 at 02:18

1 Answers1

1

The difference is managed_shared_memory follows POSIX requirements, thus emulating the parts that windows_shared_memory is missing (i.e. persistence). This is done via memory file mapping.

The downsides of managed_shared_memory seems to be interopability with other applications (that use native windows shared memory) and potentially speed upon first access. The downside of windows_shared_memory on the other hand is lack of portability between systems.

orhtej2
  • 2,133
  • 3
  • 16
  • 26