X11 protocol: error handling best practices for async requests

[Michal Suchanek]

On 26 October 2012 07:34, halfdog <me at halfdog.net> wrote:
> -----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?
>

As far as I understand from the earlier infrequent discussions on
error handling it is simply impossible to handle X11 errors so the
best thing you can do is abort in any case.

One of the issues is that the error codes are X server instance
specific so when you get an error you don't know what error it is and
it is not guaranteed that you can query the X server what it meant
because you are in an unknown broken state.

So X calls returning errors or not is really not relevant because  you
cannot handle them anyway.

When you do a lot of bookkeeping on your side you can possibly tell
what request failed (although usually not how) and determine if the
failure is critical for your application or not.

Thanks

Michal