Jinoh Kang (@iamahuman) commented about server/mapping.c:
pe_image_info_t image; /* image info (for PE image mapping) */ struct ranges *committed; /* list of committed ranges in this mapping */ struct shared_map *shared; /* temp file for shared PE mapping */
- void *shared_ptr; /* mmaped pointer for shared mappings */
Is there a reason why the section (mapping) object should be responsible for managing the server-side VMA's lifecycle? How about just returning mmap()-ed pointer for the section object on demand, and let the user free it?
For example, the desktop object doesn't really need reference to the section object itself; it merely has to access the actual shared memory.[^note]
[^note]: At least this was the impression I got from https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories. Maybe there's a use case for resizing the mapping, but I suppose that requires creating a new replacement anyway, and the object can be referenced by name in that case.