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

[Marek Chalupa]

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/20150327/40899aee/attachment.html>