<div dir="ltr">On Mon, Jul 6, 2015 at 11:53 PM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>Multiple "handles" to the same underlying server-side object from<br>
completely asynchronous contexts (different processes). I can't see<br>
that ending well at all, considering that *nothing* we have ever<br>
designed for Wayland accounts for that.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>Destruction cannot "go" anywhere. The server cannot choose to destroy a<br>
protocol object of one client at arbitrary times, even if it was<br>
requested by another client. We simply do not have the messaging for<br>
this, nor the extensive machinery required to solve the races.<br></blockquote><div><br></div><div>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.<br><br>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".<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What does "destruction" even mean? Destroying the protocol object of<br>
one client, or the underlying server-side object? Can you even define<br>
that universally?</blockquote><div><br></div><div>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. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the server-side object disappears, what happens? How could you ever<br>
define that in a way that would work for everything?<br></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Let's take this relatively simple case of one client providing a parent<br>
surface and another client providing a dialog surface that should be<br>
related to the parent. What should happen if the parent disappears?<br>
Should the client with the dialog be notified?<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or what if the server-side object gets destroyed only when the last<br>
protocol object associated with it is destroyed? A client shares an<br>
xdg_surface, stuff happens, the client destroys the xdg_surface<br>
assuming the window gets unmapped, but oops, someone else is holding a<br>
ref to it, so it actually doesn't unmap.<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What then, if the xdg_surface is shared but the related wl_surface is<br>
not, and the wl_surface gets destroyed? Xdg-shell defines what happens<br>
in a non-shared case, but how does that translate to the other client?<br></blockquote><div><br></div><div>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.<br><br><br></div></div><br></div></div>