On Thu, Mar 3, 2011 at 9:32 AM, Andreas Hartmetz <[email protected]> wrote: > Hello again and sorry for taking a few days to reply. > ... >> > - A scheme to recycle object IDs. When a new ID is needed, pick a free >> > one at random. This introduces a problem: >> > Suppose the client destroys object A with ID n, then by chance >> > immediately reuses ID n for object B. >> > The server will only receive this information later, the Wayland >> > protocol being asynchronous and the server not having to respond to an >> > object creation request, unless it goes wrong. In the meantime the >> > server could send an event intended for A which would end up at B, >> > causing Bad Things to happen - in my implementation most likely an >> > assert failure unless the objects are of the same class. >> > (This is the trickiest failure mode I could think of) >> > The suggested solution is a kind of "rendezvous" for objects where this >> > can happen, or for simplicity all objects: >> > On both client and server, have a function that needs to be called >> > twice to unregister an object ID. >> > One call from the destructor of the local object when it destroys >> > itself, one call from the remote counterpart object when it destroys >> > itself. No matter in which order the method is called, the first call >> > removes the ID<->object mapping and puts the object ID on a waiting >> > list to avoid reuse. The second call removes the ID from the waiting >> > list, making it free to reuse. >> >> Ah, yes, very good point. I was going to suggest that there could be >> an event that the server sends to acknowledge that it has bound and >> object to a client ID (whether through the bind request above or from >> the client creating a client object), but if we reuse the same ID too >> fast, then it's still unclear which object the ID refers to. That >> could be fixed by adding a serial number, but at that point I think >> your idea is better and simpler. In fact, with your idea, we can >> distinguish between events sent from an object that we've destroyed >> and server errors where the server sends an event from an object that >> never existed. >> > I've started implementing this in my project and I've hit a problem: while the > destroy() methods are basically regular methods that get an opcode the regular > way, the confirmation message also needs an opcode. > The idea I outlined above, that I maybe didn't explain optimally, contains > that a destroy request looks exactly like a destroy confirmation. That way > both > sides can handle destruction the same way: If the object was locally > destroyed, destroy the instance and send a destroy() call to the other side. > The other side will send back a destroy() when it's done destroying. Both > sides will unregister the ID when destroy() has been both sent and received, > keeping track with two boolean flags. That way exactly one destroy() call is > sent to the other side. > > In a nutshell, I think destroy() should implicitly be both a request and a > response whenever it appears in a client-created object. The methods could > actually be added implicitly to all client-created objects which wouldn't be > more of a hack than "doubling" one ocurrence of destroy() or adding a flag > like > has_destructor="true", which btw would also be fine with me.
Can't we just add a "destroyed" event to the display interface? Kristian _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
