POSIX shared memory between regular Linux and Wine processes?

Paul Gofman pgofman at codeweavers.com
Wed Jul 14 07:18:55 CDT 2021


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.



More information about the wine-devel mailing list