[ANNOUNCE] XCB 1.0 now available
jamey at minilop.net
Mon Nov 27 23:25:05 PST 2006
On Mon, Nov 27, 2006 at 02:01:04AM +0100, Juliusz Chroboczek wrote:
> > It has several advantages over Xlib, including
> Before I try it out: do you fix error handling too? I.e. is it
> possible to recover from an asynchronous protocol error?
We put a lot of thought into how to deal with both X errors and I/O
errors, and I believe you'll find that XCB handles errors quite nicely.
XCB's error handling is both simple and thread-safe, unlike Xlib. XCB
will inform you of I/O errors, and will never terminate your
application, also unlike Xlib.
For X errors, we implemented Plan 7, so called because we had to go
through six other plans first. ;-) You can make requests in either
"checked" or "unchecked" mode. If an X error occurs for an unchecked
request, the error goes into the event queue and you can process it in
your normal event loop. An error for a checked request is held aside
until you ask for the response to that request. For requests that don't
normally have responses, you can use the xcb_request_check function to
block until the server has processed that request and returned any error
that may have occurred.
For an example of XCB's error handling, see my port of libXrender's
check for broken Xinerama implementations. It originally needed some 90
lines of code, including a callback function and a global linked list.
Despite carefully using the global Xlib lock, it can't be made fully
thread-safe due to Xlib's deficient error handling (XSetErrorHandler).
With XCB, the equivalent code is about 30 lines long and fully
thread-safe without any visible locks.
If that didn't answer your question, please feel free to come discuss on
the XCB list: we'd love to hear from you.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the xorg