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