Since the Xlib multithreaded code checks the flags variable in _XFlushInt
to see if the other threads are done yet, it has to be marked volatile so
the compiler doesn't optimize out re-loading it on each trip through the
while loop and end up in an impossible-to-exit infinite loop of CPU chewing.
Part of fix for Sun bug 6409332: infinite loop in XFlushInt() on x86/32-bit
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6409332>
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Oops, cccp aliased cc for question mark. Upper-case it to avoid fail.
Signed-off-by: Will Thompson <will@willthompson.co.uk>
Signed-off-by: Daniel Stone <daniel@fooishbar.org> (sorry)
Note that a full review was not done, only for functions that receive
char/short arguments, or one of it's parameters is a function pointer
that requires char/short arguments.
The code is wrong since the first git revision, so it seens that it has
not been compiled with WORD64 for quite some time, there is also another
interesting code in xkb/XKBRdBuf.c:
<hash>ifdef WORD64
_XkbWriteCopyData32 Not Implemented Yet for sizeof(int)==8
<hash>endif
and possibly there are other similar problems.
An uninitialized or otherwise invalid condition variable can apparently
cause a hang in pthread_cond_broadcast. Ekiga, openoffice, and xine
at least are freezing as a result of event_notify never being initialized.
Signed-off-by: Brian Rogers <brian@xyzw.org>
Signed-off-by: Bart Massey <bart@cs.pdx.edu>
Author is Peter Breitenlohner <peb@mppmu.mpg.de>
Bug #17946, attachment #19443
This patch avoids the gcc warning
../../../../libX11-1.1.5/modules/im/ximcp/imDefLkup.c:223: warning: passing arg 1 of `_XimProcSyncReply' from incompatible pointer type
(same as already done at other places)
BTW: what is the difference between XIM (the type of ic->core.im)
and Xim ?
Author is Peter Breitenlohner <peb@mppmu.mpg.de>
Bug #17946, attachment #19441
This patch avoids the two gcc warnings
../../../../libX11-1.1.5/modules/im/ximcp/imRm.c:413: warning: assignment discards qualifiers from pointer target type
../../../../libX11-1.1.5/modules/im/ximcp/imRm.c:450: warning: assignment discards qualifiers from pointer target type
Note, that this as a rather crude fix of the problem (and it is really a
shame to cast name_table to non-const).
The right solution would be to declare XIMValuesList.supported_values
(in include/X11/Xlib.h) as 'const char **' (or '_Xconst char **').
This will, however, require extensive modifications in various places.
Author is Peter Breitenlohner <peb@mppmu.mpg.de>
Bug #17946, attachment #19440
Avoid a preprocessor message
<stdin>:194: warning: no newline at end of file
Two more such warnings (in XkbSAGroup.man and XkbSASetGroup.man)
seem to be caused by a truncated (or otherwise incomplete)
manpage.
Author is Peter Breitenlohner <peb@mppmu.mpg.de>
Bug #17946, attachment #19439
Define as 1 (one) as done by autoconf and the command line
option, e.g. -DX11_t, not as empty.
This avoids the gcc (3.4.6) warnings:
../../libX11-1.1.5/src/x11_trans.c:27:1: warning: "X11_t" redefined
<command line>:7:1: warning: this is the location of the previous definition
../../libX11-1.1.5/src/x11_trans.c:28:1: warning: "TRANS_CLIENT" redefined
<command line>:8:1: warning: this is the location of the previous definition
Similarly, follow the autoconf convention to define XTHREADS
and XUSE_MTSAFE_API as one.
This avoids analogous warnings when compiling libXcomposite,
libXcursor, and libXdamage.
No reason to AC_SUBST XTHREADS and XUSE_MTSAFE_API (unused).
Only convert to use "ansi prototypes" the functions warned from
compilation with "./autogen.sh --prefix=/usr", on a Linux computer.
Also, only address "trivial" compiler warning fixes in this commit.
The new .gitignore is the output of a command like:
% find . -name .gitignore -exec cat {} \; | sort | uniq
and only the toplevel .gitignore file was kept.
The xkeyboard-config keyboards generate the symbol Udiaeresis, not
U00DC. Make sure the relevant Compose sequences expect the symbol
which the keyboards actually send.
big5hkscs.h and gbk.h, added in 67e34d7a, need to be in SOURCES to
make it into the tar.
Completes 67e34d7a82.
Signed-off-by: James Cloos <cloos@jhcloos.com>
Xlib has several independent tasks that need to be performed with the
display unlocked. It does this by replacing the existing sync handler with
one of a variety of internal sync handlers. However, if multiple internal
sync handlers need to run, then the last one registering wins and
previously registered internal sync handlers are never invoked. This
manifested as a bug with DRI applications on Xlib/XCB as that requires
both an XID handler after every XID allocation, and the periodic sequence
number handler. The XID handler would win, and the sequence number handler
would never be invoked.
Fix this by unifying the internal sync handler mechanism into a single
function that calls all of the known internal sync handlers. They all need
to deal with being called when not strictly necessary now.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@freedesktop.org>
XNextEvent assumes that the event queue will be non-empty on return from
_XReadEvents, but with multiple event readers running, the previous change
could leave the queue empty on return from process_responses. Re-invoke
process_responses until the queue is non-empty.
Signed-off-by: Keith Packard <keithp@keithp.com>
As Xlib queues events internally, we must prevent multiple Xlib threads from
entering XCB to wait for an event in case the queued event is to be
delivered to the thread which didn't manage to read it. In other words, let
only one Xlib thread into xcb_wait_for_event at a time.
Jamey Sharp looked over my shoulder while making this fix and, while hating
my whitespace conventions, appears happy enough with the actual code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Xlib built --without-xcb is also vulnerable to this race, and a similar
fix might work there too.
Also, use an XID that's truly invalid while waiting for the next XID to be
requested.
Previously, Xlib/XCB used XCB's Xlib lock to prevent XCB from sending
requests between calls to Xlib's LockDisplay and UnlockDisplay macros.
Xlib/XCB then sent all of its requests using XCB's xcb_send_request, and
had to flush its requests when unlocking the display.
XCB 1.2 adds a new socket handoff mechanism, xcb_take_socket. Replace
much of the existing Xlib/XCB implementation with the use of
xcb_take_socket to take ownership of the write side of the X connection
socket, and a return_socket callback which writes any outstanding requests
with xcb_writev. This approach allows Xlib/XCB to use the same buffering
as traditional Xlib did. In particular, programs which use Xlib/XCB and
never make XCB calls will never need to hand the socket back to XCB, and
vice versa.
This allows us to discard large quantities of synchronization code from
Xlib/XCB, together with the synchronization bugs present in that code.
Several test cases which previously failed now work perfectly, including
multi-threaded ico. In addition, the infamous locking correctness
assertions, triggered when double-locking or when unlocking without a
previous lock, no longer exist, because Xlib/XCB no longer has any reason
to care more about application locking than traditional Xlib does.
Furthermore, the handoff approach provides great improvements to
performance. Results from x11perf's XNoOp test, which represented the
worst case for the lock-based Xlib/XCB:
Traditional Xlib: average 19100000/sec
Lock-based Xlib/XCB: average 3350000/sec
Handoff-based Xlib/XCB: average 17400000/sec
Thus, for no-ops, the handoff mechanism provides more than a 4x speedup to
Xlib/XCB, bringing Xlib/XCB within 9% of traditional Xlib no-op
performance. Of course, real-world workloads do not use no-op, so your
mileage may vary. In particular, since no-ops represent the worst case,
we expect real workloads to more closely match the performance of
traditional Xlib.
While removing synchronization code, we changed _XReply to not drop any
locks when calling xcb_wait_for_reply; previously, we had to carefully
avoid a deadlock between the Display lock and the XCB Xlib lock. Holding
the locks reduces implementation complexity and should not impact
applications.
Commit by Jamey Sharp and Josh Triplett.
XCB's handoff mechanism inspired by Keith Packard.
