Josh Triplett authored Mar 15, 2008 and Jamey Sharp committed Nov 04, 2008

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.