Order in which requests are processed

[Sam]

Scanning through
https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html I can't seem
to find anything that seems to require the server to always send responses
to requests in the order they were received, and process requests in the
order they were received.

Example: let's say the server receives a bunch of requests. All kinds of
requests, dealing with graphic contexts, pixmaps. Some RENDER extension
requests. And the very last request is an InternAtom request.

None of the preceding requests can possibly affect the InternAtom request
(no other, prior, InternAtom requests). Does the protocol allow the server
to send a response to this InternAtom request before sending any response to
a prior requests that requires a response; and/or before processing any
prior request that does not require a response?

[Julian Bradfield]

On 2018-10-30, Sam <s...@email-scan.com> wrote:
> Scanning through
> https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html I can't seem
> to find anything that seems to require the server to always send responses
> to requests in the order they were received, and process requests in the
> order they were received.

Interesting point. I agree with you - and I can't see any reason why
it should be required, apart from the difficulty of working out when
one can do this.
Whether client libraries/programs are written to cope with it is
another matter.

[Sam]

If it's not required, then some kind of a round-trip ping is needed. The
NoOperation request is a one-way trip only, and is not sufficient.

Currently, I am abusing the InternAtom request for this, to know when the
server processed all requests that preceded it. This is how I arrived at
this conundrum.

I am intentionally using a sub-optimal environment, where the client and the
server are across a network that includes a wireless AP. This is to make
suboptimal drawing algorithms be more visible.

I can process MotionNotify events as fast as they come in, generating a pile
of X and RENDER requests as a result. But with a couple of hops across the
network, it's surprising how many X and RENDER requests can fill up in the
intermediate network buffers, before the server goes through them; which
(especially RENDER composition) create a lot of work for the server. My
display was noticably lagging behind the pointer, as much as 2-3 seconds,
even though my client was doing nothing, waiting to receive the next event.

I fixed this by sending an InternAtom just before flushing out all my work,
and then waiting for the response to the InternAtom, which arrives only
after the server dealt with my preceding requests. Once the InternAtom
response was received, with anything that came before it getting held in
/my/ queue, the existing logic that I already had in place dealt with all
the queued up MotionNotify events, only processing the last one. No more
apparent visual lag.

This trick will only work as long as the server processes all requests
serially. If someone gets the bright idea to optimize responses out of
sequence, where possible, this will defeat this workaround. The server seems
to already be capable of throwing me MotionNotify events while it's chewing
away at the request backlog.

[Julian Bradfield]

On 2018-10-31, Sam <s...@email-scan.com> wrote:
> This trick will only work as long as the server processes all requests
> serially. If someone gets the bright idea to optimize responses out of
> sequence, where possible, this will defeat this workaround. The server seems
> to already be capable of throwing me MotionNotify events while it's chewing
> away at the request backlog.

That seems reasonable, because user-generated events are genuinely
asynchronous with respect to your request stream, and the natural
thing to do is to process them independently of the request
stream. But your request stream does have a linear order on it as part
of the protocol, and so it would be an active decision to try to
process its elements with asynchronous replies.