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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com