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