jeans/LibreELEC.tv
jeans/LibreELEC.tv
1
0
Fork 0
mirror of https://github.com/LibreELEC/LibreELEC.tv.git synced 2025-07-28 13:16:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

libxcb: update to libxcb-1.8

Browse Source 
Signed-off-by: Stephan Raue <stephan@openelec.tv>
This commit is contained in:
Stephan Raue 2012-01-12 23:20:03 +01:00
parent 1ddd56ca3f
commit 97b82dcebb
2 changed files with 1 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
packages/x11/lib/libxcb/meta
View File

@ -19,7 +19,7 @@
################################################################################ ################################################################################
PKG_NAME="libxcb" PKG_NAME="libxcb"
PKG_VERSION="1.7" PKG_VERSION="1.8"
PKG_REV="1" PKG_REV="1"
PKG_ARCH="any" PKG_ARCH="any"
PKG_LICENSE="OSS" PKG_LICENSE="OSS"

53
packages/x11/lib/libxcb/patches/libxcb-1.7-wait_for_reply.patch
View File

@ -1,53 +0,0 @@
commit 5ceeaaa4294201b3f613c07f9ec610c0e5f673c7
Author: Uli Schlachter <psychon@znc.in>
Date: Thu Aug 25 14:18:16 2011 +0200
Fix a dead-lock due to xcb_poll_for_reply
Imagine two threads:
Thread#1: for(;;) { xcb_get_input_focus_reply(c, xcb_get_input_focus(c), 0); }
Thread#2: for(;;) { xcb_poll_for_event(c); }
Since xcb_poll_for_event() calls _xcb_in_read() directly without synchronizing
with any other readers, this causes two threads to end up calling recv() at the
same time. We now have a race because any of these two threads could get read
the GetInputFocus reply.
If thread#2 reads this reply, it will be put in the appropriate queue and
thread#1 will still be stuck in recv(), although its reply was already received.
If no other reply or event causes this thread to wake up, the process deadlocks.
To fix this, we have to make sure that there is only ever one thread reading
from the connection. The obvious solution is to check in poll_for_next_event()
if another thread is already reading (in which case c->in.reading != 0) and not
to read from the wire in this case.
This solution is actually correct if we assume that the other thread is blocked
in poll() which means there isn't any data which can be read. Since we already
checked that there is no event in the queue this means that
poll_for_next_event() didn't find any event to return.
There might be a small race here where the other thread already determined that
there is data to read, but it still has to wait for c->iolock. However, this
means that the next poll_for_next_event() will be able to read the event, so
this shouldn't cause any problems.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40372
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Peter Harris <pharris@opentext.com>
diff -uNr libxcb-1.7/src/xcb_in.c libxcb-1.7-patched/src/xcb_in.c
--- libxcb-1.7/src/xcb_in.c 2010-08-13 13:43:31.000000000 +0200
+++ libxcb-1.7-patched/src/xcb_in.c 2011-09-09 06:59:26.990634243 +0200
@@ -548,7 +548,7 @@
pthread_mutex_lock(&c->iolock);
/* FIXME: follow X meets Z architecture changes. */
ret = get_event(c);
- if(!ret && _xcb_in_read(c)) /* _xcb_in_read shuts down the connection on error */
+ if(!ret && c->in.reading == 0 && _xcb_in_read(c)) /* _xcb_in_read shuts down the connection on error */
ret = get_event(c);
pthread_mutex_unlock(&c->iolock);
}