Questions about object ID lifetimes

[Pekka Paalanen]

On Tue, 19 Sep 2023 10:02:55 -0400
jleivent <jleivent at comcast.net> wrote:

> 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?

I believe we tend to call them just race conditions, or racy messages.

Btw. about grouping messages, we hand-roll protocol for that too: there
is wl_surface.commit to latch a bunch of state, and the shell related
extensions have the final 'configure' event, and it's common to have a
'done' event on an interface that splits sending state into multiple
events. Several input interfaces have 'frame' event for the same. This
helps the receiving side to wait for the complete state transmission
before acting on it.

It is inconvenient to have to design all this by hand every time in a
new interface, and I agree it would be nice if the wire protocol
foundation offered a solution somehow, but I'm not sure how that should
look in the hypothetical Wayland 2.

> > > 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

Yeah, the free list could be a FIFO instead of a LIFO.

> 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.

I'm wary of solutions that reduce the risk but do not eliminate it. If
a protocol interface design turns out racy, it would be best to find
that out sooner than later, and evaluate fixing it. Reproducibility
helps analysis.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230920/1e9d9198/attachment-0001.sig>