In 3D Slicer, we have a file-free ITK image IO plugin that we use to send/receive images in Slicer modules that are loaded as a dynamic library. You just register this plugin as any the other IO plugins. To pass an image to a module you don’t even need to write a file, just create a special filename (in our case it is slicer:<scene_memory_address>:<volume_node_id>) that the IO plugin recognizes and parses to get the memory address of the image. See source code of the IO plugin here and see how you specify an input volume here.
The advantage of this custom IO plugin technique that there is zero copy (not even in memory) and the reader does not need to know anything about this special IO plugin. It just gets a filename and asks ITK to read it and if it happens to be a shared memory address then it gets the image from there, otherwise the appropriate IO plugin will read the data from file.
There are a few disadvantages compared to simple file IO. There are a few more files to maintain and test (on all operating systems you support, at each major ITK update, etc.). There is also a disadvantage in running processing algorithms in the same process: 1. an error in the processing algorithm can crash the entire application; 2. it is not possible to force stopping a processing thread if that becomes non-responsive or takes too much resources (while it is easy to terminate a child process at any time).
This shared memory mechanism was essential 10-15 years ago. However, as @dzenanz noted above nowadays there is very little overhead in writing/reading files, so if you use a simple file format and no compression then the file IO time is typically negligible compared to the processing time.