cross-client surface references

[Bill Spitzak]

On Mon, Jul 6, 2015 at 11:53 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:


> Multiple "handles" to the same underlying server-side object from
> completely asynchronous contexts (different processes). I can't see
> that ending well at all, considering that *nothing* we have ever
> designed for Wayland accounts for that.
>

I think you already have that for all the global objects. Two different
clients can create a proxy for the same global object. Yes this also
creates multiple C structures in the server, to keep track of the actual
client communication, but for most documentation you act as though there is
one "object" that all the clients are "sharing". The same solution would be
used here.


> Destruction cannot "go" anywhere. The server cannot choose to destroy a
> protocol object of one client at arbitrary times, even if it was
> requested by another client. We simply do not have the messaging for
> this, nor the extensive machinery required to solve the races.
>

There is the wl_registry.global_remove event. However you are right there
is no matching destroyed event for objects that are created by clients.

If one was added I think it could be done the same way: rather than adding
a destroyed event to every object, an event similar to global_remove could
be added, perhaps to the same interface that creates and uses "keys".

What does "destruction" even mean? Destroying the protocol object of
> one client, or the underlying server-side object? Can you even define
> that universally?


Destruction of the underlying server-side object. As you point out, it is
not possible for clients to destroy global objects such as the
wl_compositor.

If the server-side object disappears, what happens? How could you ever
> define that in a way that would work for everything?
>

It works like global objects do after the global_remove event is sent. The
client can send requests for these objects before it gets the event, so the
server must be prepared to handle those requests after destruction. I think
this has already been discussed (though on the client end) as "zombie"
objects, and the compositor is already doing this in a few cases for
objects that depend on input devices that can disappear.

Let's take this relatively simple case of one client providing a parent
> surface and another client providing a dialog surface that should be
> related to the parent. What should happen if the parent disappears?
> Should the client with the dialog be notified?
>

Ideally yes, though if there is no such event the child will probably be
able to figure out what happened. I would expect if it made a child surface
that the surface would unmap when the parent was unmapped.


> Or what if the server-side object gets destroyed only when the last
> protocol object associated with it is destroyed? A client shares an
> xdg_surface, stuff happens, the client destroys the xdg_surface
> assuming the window gets unmapped, but oops, someone else is holding a
> ref to it, so it actually doesn't unmap.
>

Yes you are correct, the simplistic "reference count" implementation where
the destruction only happens after all clients send the destroy request
will cause problems. Instead the first destroy request has to work.


> What then, if the xdg_surface is shared but the related wl_surface is
> not, and the wl_surface gets destroyed? Xdg-shell defines what happens
> in a non-shared case, but how does that translate to the other client?
>

I can't seem to find and description of what should happen if you destroy a
wl_surface and do not destroy the xdg_surface first. I am guessing what
happens is a protocol error for the client making the destroy request on
the wl_surface. To avoid this the client must destroy the xdg_surface
first, which means the destruction must work even if another client has the
surface. So this is also an example where simple reference-counting won't
work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150707/ff4eb049/attachment.html>