Finishing the network protocol
krh at bitplanet.net
Thu Mar 3 06:58:14 PST 2011
On Thu, Mar 3, 2011 at 9:32 AM, Andreas Hartmetz <ahartmetz at gmail.com> 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?
More information about the wayland-devel