X11 protocol: error handling best practices for async requests

[Adam Jackson]

On 10/24/12 2:09 PM, halfdog wrote:

> Could someone please point me to the documentation about best practice
> when dealing with asynchronous requests on client side. If I understand
> [1] correctly, some requests, when successful, will not produce any
> reply. Hence a client side library cannot wait on a reply or error from
> the server, there might never be any.
>
> What is the best practice for client-side implementation, when receiving
> an unexpected error for such a request? Abort immediately since
> connection might be out of sync? Pass it to the user side of the
> client-side API via some error handler? How should user-side handle it?

The default Xlib error handler simply aborts.  In most cases there's no 
recovering anyway, like if someone else destroys the Window you were 
hoping to render to.

Most toolkits have a "critical section" pattern where, if doing 
something sufficiently complicated that error handling is warranted, 
they will push an error handler, do some stuff, force a reply with 
XSync(), and pop.  Since replies/events/errors are guaranteed to be 
in-order, either the error handler gets called or everything succeeded. 
  This has a modest performance penalty since it forces a roundtrip. 
It's also annoying to get right in the face of multiple threads and 
multiple display connections, since Xlib's error handler is global 
across both threads and Displays.

If instead you have a callback system based on the wire sequence number, 
the client library could call back to the application when the protocol 
has received an r/e/e for a request later than the one whose errors you 
wanted to trap.  I believe it's possible to build this in XCB, but 
again, most apps can't meaningfully recover anyway.

- ajax