-----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----- _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
