Questions about object ID lifetimes

jleivent jleivent at comcast.net
Tue Sep 19 14:02:55 UTC 2023


On Tue, 19 Sep 2023 16:26:37 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> ...
> > But aren't those fast frame updates done through shared fds?  Hence
> > not part of the wire protocol, and would not be impacted by
> > increasing the length of messages on the wire?  
> 
> No. They are messages sent on the wire, telling "there is a new image
> on that other fd I shared with you before, use that now", and so on.
> That is usually a handful of requests per frame.

Didn't realize that.
> 
> I would argue that "speculative" is not the right word here, it was
> never intended.

How about: there are "anomalous" messages and state changes?


> > tl;dr: protocol asynchrony leads to speculation that can result in
> > the two sides disagreeing about the correct state of the world.    
> 
> We avoid that with careful protocol design in XML. There is exactly
> that kind of situation in the xdg-family of extensions and it is
> solved by sending a serial with the events and acking that serial
> when the client acts on the events.
> 
> It's a known caveat.

OK.

This might help reduce those anomalous messages and be compatible with
Wayland 1.  Reduce the greediness of object ID reuse by:

- not reusing any IDs unless at least some minimum number (256?)
  are free

- reuse the freed ones in LRU fashion

There are other variations of this - the point of all being to increase
the time between when any ID becomes free and when it is reused but
without causing the ID maps to grow unreasonably large, or causing their
maintenance to slow down.

Increasing the time delay between freeing and reuse (such as with a
higher minimum free threshold above) would probably lead to lower
probability of anomalous messages. You could make this tunable through
an environment variable.

Note that the two sides don't have to agree to use this less-greedy ID
allocation for either side to use it - and it's really only important
for servers anyway.



More information about the wayland-devel mailing list