4d828c5eba
But do still print a full backtrace, on platforms where that's supported. This commit follows the spirit of Novell's libxcb-sloppy-lock.diff. I strongly opposed proposals like this one for a long time. Originally I had a very good reason: libX11, when compiled to use XCB, would crash soon after a locking correctness violation, so it was better to have an informative assert failure than a mystifying crash soon after. It took some time for me to realize that I'd changed the libX11 implementation (for unrelated reasons) so that it could survive most invalid locking situations, as long as it wasn't actually being used from multiple threads concurrently. The other thing that has changed is that most of the code with incorrect locking has now been fixed. The value of the assert is accordingly lower. However, remaining broken callers do need to be fixed. That's why libXCB will still noisily print a stacktrace (if possible) on each assertion failure, even when assert isn't actually invoked to abort() the program; and that's why aborting is still default. This environment variable is provided only for use as a temporary workaround for broken applications. Signed-off-by: Jamey Sharp <jamey@minilop.net> Acked-by: Josh Triplett <josh@freedesktop.org> |
||
|---|---|---|
| doc | ||
| src | ||
| tests | ||
| tools | ||
| .gitignore | ||
| COPYING | ||
| INSTALL | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| acinclude.m4 | ||
| autogen.sh | ||
| configure.ac | ||
| xcb-composite.pc.in | ||
| xcb-damage.pc.in | ||
| xcb-dpms.pc.in | ||
| xcb-glx.pc.in | ||
| xcb-randr.pc.in | ||
| xcb-record.pc.in | ||
| xcb-render.pc.in | ||
| xcb-res.pc.in | ||
| xcb-screensaver.pc.in | ||
| xcb-shape.pc.in | ||
| xcb-shm.pc.in | ||
| xcb-sync.pc.in | ||
| xcb-xevie.pc.in | ||
| xcb-xf86dri.pc.in | ||
| xcb-xfixes.pc.in | ||
| xcb-xinerama.pc.in | ||
| xcb-xlib.pc.in | ||
| xcb-xprint.pc.in | ||
| xcb-xtest.pc.in | ||
| xcb-xv.pc.in | ||
| xcb-xvmc.pc.in | ||
| xcb.pc.in | ||
About libxcb
============
libxcb provides an interface to the X Window System protocol, which replaces
the current Xlib interface. It has several advantages over Xlib, including:
- size: small library and lower memory footprint
- latency hiding: batch several requests and wait for the replies later
- direct protocol access: one-to-one mapping between interface and protocol
- proven thread support: transparently access XCB from multiple threads
- easy extension implementation: interfaces auto-generated from XML-XCB
Xlib can also use XCB as a transport layer, allowing software to make
requests and receive responses with both, which eases porting to XCB.
However, client programs, libraries, and toolkits will gain the most
benefit from a native XCB port.
Please report any issues you find to the freedesktop.org bug tracker,
at:
<https://bugs.freedesktop.org/enter_bug.cgi?product=XCB>
Discussion about XCB occurs on the XCB mailing list:
<mailto:xcb at lists.freedesktop.org>
<http://lists.freedesktop.org/mailman/listinfo/xcb>
You can obtain the latest development versions of XCB using GIT.
For anonymous checkouts, use:
git clone git://anongit.freedesktop.org/git/xcb/libxcb
For developers, use:
git clone git+ssh://git.freedesktop.org/git/xcb/libxcb