Guarantees of order of X events vs requests

[Adam Jackson]

On Wed, 2010-10-20 at 11:34 +0200, Eirik Byrkjeflot Anonsen wrote:
> What guarantees does X give when it comes to the order of events
> generated in relation to processing of the requests sent by the client?

Between clients, request streams generally do not have any ordering,
unless you impose one with the Sync extension.

Chapter 12 of the protocol spec spells it out in detail:

"Whether or not a server is implemented with internal concurrency, the
overall effect must be as if individual requests are executed to
completion in some serial order, and requests from a given connection
must be executed in delivery order (that is, the total execution order
is a shuffle of the individual streams). The execution of a request
includes validating all arguments, collecting all data for any reply,
and generating and queueing all required events. However, it does not
include the actual transmission of the reply and the events. In
addition, the effect of any other cause that can generate multiple
events (for example, activation of a grab or pointer motion) must
effectively generate and queue all required events indivisibly with
respect to all other causes and requests. For a request from a given
client, any events destined for that client that are caused by executing
the request must be sent to the client before any reply or error is
sent."

> (Also, of course: To which degree does various implementations of X
> actually fulfill these guarantees?)

The sample implementation is strictly ordered; all events generated from
request N are added to the reply buffer before request N+1 is processed.
Writes from server to client are buffered, so you may not hear them for
a while.

> Some specific questions:
> 
> X events have a "serial" value.  I expect that any event delivered by X
> will reflect the state after the request number "serial" (and all
> preceding requests) have been processed.  Is this correct?

From the protocol spec:

"Every core event (with the exception of KeymapNotify) also contains the
least significant 16 bits of the sequence number of the last request
issued by the client that was (or is currently being) processed by the
server."

> Can I also assume that the X event will reflect the state before any
> requests with a later serial number is processed?

Correct.

> (And I assume that "serial" is monotonically increasing, except on
> wrap-arounds...)

Correct.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20101020/b026d023/attachment.pgp>