On Mon, 18 Sep 2023 14:06:51 +0300
Pekka Paalanen wrote:
> On Sat, 16 Sep 2023 12:18:35 -0400
> jleivent 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.
By taking turns. Each side would, after queuing up a batch of
messages, add an "Over!" message (from the days of half-duplex
radio communications) to the end of that queue, and then send the whole
queue (retaining its sequence). Neither side would send a message
until it receives the other side's "Over!" message, and until the
higher levels above libwayland have had a chance to examine all
messages prior to "Over!" in order to avoid sending an inconsistent
message or even committing to a state incompatible with later messages.
>
> > 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.
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?
>
> > 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.
Not adding. Dealing with the already existing (or if any new ones are
added) ping/pong pairs. Or any messages that really need to be timely,
hence can't wait for messages in front of them to be fully processed.
That could apply to any real-time requirements, like the gaming mice
messages you mentioned above. But doing this in general is hard unless
the messages are irrelevant to the rest of the protocol (hence commute
with everything else), like ping/pong are.
>
>
> On Sun, 17 Sep 2023 15:28:04 -0400
> jleivent 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.
So no changes to the wire format are possible under any circumstances
in Wayland 1?
>
> > 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.
Encoding more into the message is only needed if there are no
destructor request acks (the equivalent of wl_display::delete_id, but
in the opposite direction). But I was wondering why not do it for
robustness.
The signature isn't very big, but it's probably not needed even for
robustness. What's needed is the target object type/version
information. Since from that both sides know the signature. The issue
is just how to add robustness to the object ID -> type/version
mapping, which is the source of many problems. The signatures ar
