236f914ea7
On FreeBSD MSG_WAITALL on a non-blocking socket fails immediately if less bytes than were asked for are available. This is different than the behavior on linux where as many bytes as are available are returned in this case. Other OS apparently follow the FreeBSD behavior. _xcb_in_read() is used to fill xcb's read buffer, thus this function will call recv() with a big length argument (xcb's read buffer is by default 16 KiB large). That many bytes are highly unlikely to be available in the kernel buffer. This means that _xcb_in_read() always failed on FreeBSD. Since the socket was still signaled as readable by poll(), this bug even resulted in a busy loop. The same issue is present in read_block(), but here it is slightly different. read_block() is called when we read the first few bytes of an event or a reply, so that we already know its length. This means that we should be able to use MSG_WAITALL here, because we know how many bytes there have to be. However, that function could busy loop, too, when only the first few bytes of the packet were sent while the rest is stuck somewhere on the way to us. Thus, MSG_WAITALL should be removed here, too. Thanks to Christoph Egger from Debian for noticing the problem, doing all the necessary debugging and figuring out what the problem was! This patch is 99% from debian. Thanks for all the work. This bug was introduced in commit |
||
|---|---|---|
| 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