[PATCH] Destroy resources when destroying input and output

[Pekka Paalanen]

On Thu, 8 May 2014 19:32:12 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Tue, Dec 31, 2013 at 3:37 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > You cannot just go and destroy wl_resources, because there are
> > clients using them - that is why the wl_resources exist in the
> > first place. Clients use all protocol objects they have, and if the
> > protocol does not say an object is destroyed, then it must be legal
> > to use it, regardless of what happens in the server.
> >
> > If you can guarantee, that clients know the protocol object has
> > gone away without any races, then the clients have already
> > destroyed the protocol objects themselves, which means that you
> > have no wl_resources to destroy in the list.
> >
> > If you cannot guarantee that, then the protocol objects
> > (wl_resources) must continue to exist in such a way, that clients
> > do not get a fatal protocol error when using them. The objects just
> > do nothing. This state is called "inert".
> >
> > If this principle is broken, it usually leads to races between the
> > server and the client, which sometimes leads to a fatal protocol
> > error and causes disconnection of the client. This happens, when the
> > server destroys a wl_resource, and then receives a request from the
> > client for that destroyed resource. The client may have sent the
> > request even before the wl_resource was destroyed in the server, at
> > which point it was a legal request from the client's perspective
> > (this is the essence of the race).
> >
> > However, since wl_output interface contains no requests, your patch
> > might be right. A client cannot send a wl_output request after the
> > wl_resource has been destroyed in the server, because the interface
> > has no requests.
> >
> > The wl_output could still be used as an argument to other requests
> > in other interfaces, though. Whether that is fatal, or just
> > silently gets turned into NULL argument in libwayland-server, I do
> > not remember off-hand. Would be best to verify what happens in that
> > case, since it must not be fatal to the client.
> >
> 
> Yes, I just looked it up.  If a client sends a request with the output as
> an argument after the output gets destroyed, the client will get an
> INVALID_OBJECT protocol error and disconnect.  This is a problem.
> 
> 
> >
> > If this patch leads to a race with possibly a protocol error as the
> > result (think about output hot-unplug), then I think you would need
> > to turn the wl_resource into an inert object instead of destroying
> > it directly.
> >
> 
> The way to do this would be to set dummy handler and call
> wl_resource_set_destructor(resource, NULL);  This leaves the resource inert
> and allows us to destroy the underlying object.  The resources will get
> cleaned up when the client quits.

Looking at it in general, there is one more fun complication.

If the inert object has requests in its interface, that create new
objects, the server cannot just ignore those requests. I think the
server will need to actually create new objects if requested, but
make those inert too. Otherwise there would again be a mismatch
between the server and the client on which objects exist.


Thanks,
pq