[RFC PATCH 3/4] winevulkan: Add support for named video resources.

[Paul Gofman]

On 5/4/21 23:21, Derek Lesho wrote:
> 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?

I guess when the graphics API accepts the handle, it may map the shared
memory as well as get the handles for all the referenced objects. When
it closes the shared handle, it should close the inner handles as well.
If a process holding those handles dies (would it be the original
creator or any process using the shared object), all the handles are
closed by wineserver. I might be missing a lot of important details now
of course.