_XReply drops the Display lock, so the value of dpy->request may change
before _XReply is called again.
I discovered this by inspection a year or two ago. I'm pretty confident
in the claim, and nobody has come up with an argument for why it's safe
despite appearances.
Previously, process_responses (the common code for _XReply,
_XReadEvents, and _XEventsQueued) took the current request sequence
number as an argument, and did some highly complicated processing to
attempt to process responses in order across threads. This didn't
actually work.
Now, process_responses handles responses in order, by adding condition
variables to the list of outstanding requests in
dpy->xcb->pending_requests, and blocking on them when those requests
should get processed to allow _XReply to process them; if actually
called from _XReply, it returns when _XReply's request should get
processed. _XReply broadcasts on the condition variable after it has
read its reply and re-acquired the display lock.
Another great commit brought to you by Jamey Sharp, Josh Triplett, the
Gobby collaborative text editor, conspy, and ridiculous amounts of SSH
forwarding.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Remove long compositions that override (or get overriden by) later shorter
compositions, e.g. a four-key compose sequence that gets overriden by a
later three-key compose sequence.
Some XKB functions didn't correctly call LockDisplay or UnlockDisplay.
This patch fixes at least some instances of that problem.
Thanks to Magnus Kessler <Magnus.Kessler@gmx.net> for finding these bugs
and proposing a fix, which this patch is based on.
Rename all instances of "XCL" to Xlib/XCB-derived names.
The only user-visible change: rename the include file <X11/xcl.h> to
<X11/Xlib-xcb.h>; programs will need to change their #include lines to match.
Remove the XCL cast inlines from Xlib-xcb.h.
We can never change the libX11 soname, and we don't want to commit to never
changing the public Xlib/XCB functions, so split them into a separate library
libX11-xcb. This also means that a program linked solely against libX11
should work with either Xlib or Xlib/XCB, which will make life easier for
package maintainers.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Acked-by: Jamey Sharp <jamey@minilop.net>
No more recursive mutexes, no more banging XCB's I/O lock in-place, and
reduces the differences between the previous stable release and an
XCB-enabled one. Sadly, Xlib's pluggable thread functions work again
too, now. I apologize to the world.
Port to X11R7 of Sun bug fix 4061225 by Alex Chen for X11R6 - when failing to
connect on a named pipe, try a Unix socket first, to better support people who
replace their X servers with ones that don't support named pipe transport.
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4061225>
Setting the ChangeLog rule as phony forces it to be re-run even when the
ChangeLog file already exists. Research indicates .PHONY is portable to BSD and
Solaris make.
(cherry picked from b8a98809ed commit)
Setting the ChangeLog rule as phony forces it to be re-run even when the
ChangeLog file already exists. Research indicates .PHONY is portable to BSD and
Solaris make.
