6310475e23
It's possible to call xcb_wait_for_reply more than once for a single request. In this case we are nice and let reply waiters continue so that they can notice that the reply is not available anymore. Otherwise an event waiter could just signal the reply waiter that got its reply to continue but leave a waiter for an earlier reply blocked. Below is an example sequence for reproducing this problem. thread #1 (XNextEvent) - waits for events thread #2 (XSync) - executes request #2 - waits for reply #2 thread #1 - reads reply #2 - signals waiter of reply #2 to continue - waits for events thread #2 - handles reply #2 thread #3 (XCloseDisplay) - executes request #3 - waits for reply #2 thread #1 - reads reply #3 - nobody is waiting for reply #3 so don't signal - wait for events Of course it may be questionable to wait for a reply twice, but XCB should be smart enough to let clients continue if they choose to do so. Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi> Signed-off-by: Jamey Sharp <jamey@minilop.net> |
||
|---|---|---|
| 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-dri2.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-xinput.pc.in | ||
| xcb-xkb.pc.in | ||
| xcb-xprint.pc.in | ||
| xcb-xselinux.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, simple library, and lower memory footprint
- latency hiding: batch several requests and wait for the replies later
- direct protocol access: interface and protocol correspond exactly
- 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