[RFC wayland 1/2] server: implement intact resources

[Marek Chalupa]

Hi,

so I changed my patches so that they can handle the new_id use-case. I've
been testing them now for some time and it looks working.
Unfortunately, the change needed to dig more into wayland, so it is more
bug-prone. This is still just an alternative to your patches.
A benefit I see in my patches is that if we'll ever need make some another
similar changes, this series prepares a ground for it.


On Fri, Mar 27, 2015 at 3:54 PM, Marek Chalupa <mchqwerty at gmail.com> wrote:

>
>
> On Tue, Mar 24, 2015 at 5:47 AM, Hardening <rdp.effort at gmail.com> wrote:
>
>> Le 19/03/2015 09:11, Marek Chalupa a écrit :
>> > When server looses some capability (like pointer or keyboard),
>> > it takes some time to get this information to clients.
>> > When client sends request with new_id argument to the object
>> > that has been just destroyed on server-side (client
>> > does not know about it yet), we still have to create the resource.
>> > If we wouldn't do it then the client will get invalid id error once it
>> > tries to use the new object. But if we create it, then we have to
>> > take care that all the requests but destructor are ignored,
>> > because we do not have the server-side object anymore.
>> > (eventually, client will destroy the resource, because
>> > it will get the information about server-side object destruction)
>> >
>> > This patch solves this ugly race by adding wl_resource_set_intact()
>> > function that marks the resource as intact. When resource is intact
>> > it ignores all requests and events but destructors. The trick is in
>> > adding flag into the request's siganture that says: "hey! I'm
>> > destructor". Server then can skip non-destructor actions on intact
>> > resource.
>> >
>>
>> Hello Marek,
>> nice to have some feedback on this subject. I like your implementation
>> (and you have a unitary test which is really nice), anyway I feel like
>> it doesn't handle the case of inert objects that are requested with a
>> method that "return" an object. For example an inert seat that is
>> requested for get_keyboard(), in this case I think should we should bind
>> an inert keyboard. I have worked on this subject to solve that exact
>> problem. Today the seat can't be released because: we don't have the
>> method to do it, and we have the race problem that prevent us from
>> freeing the seat.
>>
>> Regards.
>>
>>
> Yeah, you're right. When the object is inert, then it won't call anything
> but destructor, which would break new_id messages on this object... OK,
> this could be solved by looking into the signature for new_id arg, so the
> new condition would be:
>
> if (is_inert && (!message_is_destructor || !has_new_id))
>       do_not_invoke
>
> And then programmer must check if the resource is innert when creating new
> resource for new id (which would not be much pain, since usually we don't
> want to do anything with inert resource, so we'd check for it anyway).
>
> Anyway, In you're approach there's this problem solved by inheriting the
> inertness from parent interface, which is really nice.
>
>
>
>
>> --
>> David FORT
>> website: http://www.hardening-consulting.com/
>>
>>
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150410/5f688ef5/attachment.html>