On 5/4/21 4:13 PM, Paul Gofman wrote:
On 5/4/21 23:05, Derek Lesho wrote:
On 5/4/21 3:56 PM, Paul Gofman wrote:
Can't those handles be just, say, mapping handles with the specific resource description, fd etc. data filled in and interpreted by the interested graphic layers?
The main reason why this wouldn't be feasible is the edge case of a process which creates a shared resource then shuts down. The process into which the resource was copied would still have an open handle to the mapping, but the mapping wouldn't hold a reference to the actual resource.
If a separate process (say, ntoskrnl.exe) can hold all the required data independently of the process which created the shared resource, can't shared memory hold that instead (possibly using some other global [named?] objects already supported by wineserver?
I think the problem is, if you find a way to store a reference to the object in the shared memory object, how do you know when to release that reference once the shared memory object is destroyed. As for making all the objects global, I'm not sure how that solves the problem, what code is releasing the reference that was in the shared memory before destruction?