POSIX shared memory between regular Linux and Wine processes?

Sebastian M. Ernst ernst at pleiszenburg.de
Wed Jul 14 07:08:50 CDT 2021


Hi Paul,

>     can you share any details on the supposed use case for that?

sure. I use Wine mainly for scientific computing where e.g. part of a
simulation is implemented for Windows only while the "rest" runs
natively on Linux. In Linux processes, I must "simply" call methods in
Windows DLLs and pass pointers (to large multidimensional arrays) to
them with as little as possible overhead. I have developed my own
generic tooling for this for CPython over the years which essentially
serializes the data (or just copies the memory contents) and ships it
back and forth via sockets, trying to keep the madness on both sides in
sync as good as possible:

https://github.com/pleiszenburg/zugbruecke/tree/develop

It works fine but does not really scale well to larger quantities of
data as you can probably imagine.

If I had a relatively easy to handle option of somehow actually sharing
any form of pointer between my Linux processes and my Windows DLL
functions (called via a separate Wine processes), it would open up a
bunch of very interesting possibilities. I am aware of the option of
turning my simulations into "actual Wine apps" which could then access
both Linux and Windows libraries, i.e. no need to share memory between
processes, but this is not exactly a very trivial, sustainable or easy
to distribute solution.

> [...] mmap() [...]

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?

Best regards,
Sebastian



More information about the wine-devel mailing list