X11 protocol: error handling best practices for async requests

[halfdog]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Jackson wrote:
> 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.

Thanks for the explanation. With this information and the comments
from the libx11-1.4.99.1/src/Sync.c I believe, that I understand the
X11:GetInputFocus workaround used to trigger the sync-reply and the
considerations that lead to that pattern. Since this seems to be best
practice, would it make sense to add a comment about this to the next
X11R7.8 specification error handling section (chapter 4)?

Apart from that, when searching for articles or posts on that topic, I
think, that since such an sync/error handling question or similar
variants have not been posed in the past frequently (or at least I
have not found them), that only X-protocol requests with nearly no
chance to cause an error during normal operation have no reply, while
any request with a modest chance of failure will always send a
OK-reply. Is this assumption of specification best practices correct
for most X11 or extension calls? Are there extensions with significant
diversion from that principle?

hd

- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlCKINoACgkQxFmThv7tq+6ZkQCgkrjl8AtugaHCEnGLJJOPwFuX
W4gAnRVK4D63v3VCvURz6B4bzIkhJcH/
=TfIn
-----END PGP SIGNATURE-----