On Mon, 18 Sep 2023 11:31:18 -0400
jleivent wrote:
> 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?
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.
Likewise, every pointer motion event is one or multiple wire events.
Shared fds are used for sharing big chunks of data mostly, that is,
shared memory. But we don't use shared memory messaging nor locks. All
messaging is Wayland messages over the socket. After all, the XML files
describe wire messages.
We want everything to be in the same protocol stream as much as
possible to reduce race possibilities. If we had shared memory
messaging in addition to the unix socket, that would be two mutually
async protocol streams in the same direction. That would be quite a
pain, as we've learnt from Xwayland (you have both Wayland and X11
connections between the same two entities; as another matter, libX11 is
really eager to have blocking roundtrips, so if libwayland would also
block for something, a deadlock is practically guaranteed eventually).
> >
> > > 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.
There are no existing mandatory ping/pong messages. Some extensions
have some, but all extensions are by definition optional from the
libwayland point of view.
Wayland messages are strictly ordered per direction, there is zero
expectation or guarantee that anything could be re-ordered at
libwayland level.
> That could apply to any real-time requirements, like the gaming mice
> messages you mentioned above. But doing this in gen
