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

[Derek Lesho]

On 5/4/21 4:31 PM, Paul Gofman wrote:
> 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.
The problem is not with the graphics APIs closing the handles they use 
to get the FDs or the shared memory handles, the problem is with the 
user code closing the shared memory object and wine having no way to 
know how to release the reference that now-destroyed shared memory holds 
to the fd object.  This also assumes that there is a indeed a way to 
hold a global reference to the fd object from the shared memory, which I 
don't think there is.
> 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.
>