Questions about object ID lifetimes

[Pekka Paalanen]

On Sat, 16 Sep 2023 12:18:35 -0400
jleivent <jleivent at comcast.net> wrote:

> The easiest fix I can think of is to go full-on half duplex.  Meaning
> that each side doesn't send a single message until it has fully
> processed all messages sent to it in the order they arrive (thankfully,
> sockets preserve message order, else this would be much harder).
> Have you considered half duplex?

Never crossed my mind at least. I can't even imagine how it could be
implemented through a socket, because both sides must be able to
spontaneously send a message at any time.

> Certainly, it would mean a loss
> of some concurrency, hence a potential performance hit.  But probably
> not that much in this case, as most of the message back-and-forth in
> Wayland occurs at user-interaction speeds, while the speed-needing stuff
> happens through fd sharing and similar things outside the protocol. I

That user interaction speed can be in the order of a kilohertz, for
gaming mice, at least in one direction. In the other direction, surface
update rate is also unlimited, games may want to push out frames even
if only every tenth gets displayed to reduce latency. Also truly
tearing screen updates are being developed.

> think it can be made mostly backward compatible. It would probably
> require some "all done" interaction between libwayland and higher
> levels on each side, but that's probably (hopefully) not too hard.
> There may even be a way to automate the "all done" interaction to make
> this fully backward compatible, because libwayland knows when there are
> no more messages to be processed on the wire, and it can queue-up the
> messages on each side before placing them on the wire.  It might need
> to do things like re-order ping/pong messages with respect to the
> others to make sure the pinging side (compositor) doesn't declare the
> client dead while waiting.  But that seems minor, as long as all such
> ping/pong pairs are opaque to the remainder of the protocol, hence
> always commute with other messages.

If you mean adding new ping/pong stuff, that doesn't sound very nice,
because Wayland also aims to be power efficient: if truly nothing is
happening, let the processes sleep. Anyone could still wake up any
time, and send a message.


On Sun, 17 Sep 2023 15:28:04 -0400
jleivent <jleivent at comcast.net> wrote:

> Has altering the wire format to contain all the info needed for
> unambiguous decoding of each message entirely within libwayland without
> needing to know the object ID -> type mapping been considered?

Not that I can recall. The wire format is ABI, libwayland is not the
only implementation of it, so that would be Wayland 2 material.

> It would make the messages longer, but this seems like it wouldn't be
> very bad for performance because wire message transfer is roughly
> aligned with user interaction speeds.

We need to be able to deal with at least a few thousand messages per
second easily.

The overhead seems a bit bad if every message would need to carry its
signature.

> Also, for any compositor/client pair, as long as they both use the same
> version of libwayland, the necessary wire format change would not
> result in compatibility issues.  It would for static linked cases,
> or similar mismatching cases (flatpak, appimage, snap, etc. unless
> the host version is mapped in instead of the packaged one somehow).
> There also seem to be unused bits in the existing wire format so that
> one could detect an a compositor/client incompatibility at least on one
> end.

We've never had the requirement for compositor and clients to use the
same minor version of libwayland. There are also completely independent
Wayland implementations in other languages that expect to be
interoperable. Breaking all that seems unacceptable.

What unused bits did you find?

> I'm not suggesting that unambiguous decoding of all messages is a
> sufficient fix, but it is a necessary one.  There are still speculative
> computation issues that it wouldn't resolve alone.

I didn't understand what is speculative. There is no roll-back of any
kind on anything, what's computed is final.


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/20230918/33920d10/attachment.sig>