Finishing the network protocol

[Kristian Høgsberg]

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?

Kristian