On 7/14/21 15:08, Sebastian M. Ernst wrote:
Thanks for the explanation. I have considered playing with an mmap-based approach directly, maybe even putting the mapped file itself into a tmpfs or /dev/shm, but I have not had the time for this yet. Long story short and I may be fundamentally misunderstanding something here: Would not any approach like this still involve multiple copies of my data or is there a way to actually have a transparent, common memory space of some kind? Does not something like this always go at least through the OS' VFS layer hence slowing down memory access?
If your Windows DLL cooperates you just need to create file mappings on Windows DLL side with a named file which can also be opened on the Unix side and used with mmap. The memory shared this way is just a shared memory (just backed by the file which file might be updated with some delay but not the memory mapped to the processes). It has no principle differences to POSIX shm you linked in this regard. Please note that while you can use shared memory this way you might still not be able to pass pointers directly (regardless of the Unix or Windows API you use to share the memory). The memory, while physically shared, might be mapped to different addresses in different processes, so the pointers still won't be valid. You can try to overcome that by mapping the shared memory at fixed addresses on both Windows (MapViewOfFileEx accepts mapping address) and mmap() which also accepts the address (Linux also has MAP_FIXED_NOREPLACE flag nowadays which might be helpful in this case). But this can fail on either side as the selected memory range might get randomly busy by something else in the process.