Re: [Xcb] [RFC PATCH] New XCB socket handoff mechanism for Xlib/XCB and other libraries

[Jamey Sharp]

On Sat, Mar 15, 2008 at 09:36:37PM -0700, Jamey Sharp wrote:
> Please review and provide comments. We hope to commit these patches and
> release new versions of XCB and Xlib/XCB soon.

Here are the bugs we currently know about that are keeping us from
committing these patches as-is. We still believe they're suitable for
testing right now, as the bugs are in rarely-encountered corner cases.
In fact I'm quite pleased that our testing methodology caught these. :-)

- KDE's taskbar, "kicker", after many hours, syncs too late and hangs.

  I can reliably reproduce this by leaving my desktop along for 5.5
  hours or so, but Josh and I are baffled by the problem. We already
  fixed a bug that looks identical, and can't see why the fix might be
  failing. If somebody else could reproduce the problem and maybe spot
  the cause, we'd appreciate it.

- The glue between Xlib and XCB is not 64-bit clean.

  XCB uses "unsigned int" for sequence numbers, but Xlib uses "unsigned
  long". These types are part of the ABI of both libraries, making them
  difficult to change. There are a few ways we could address this, and
  we haven't decided on one yet. Patches welcomed! :-)

  One side effect of this bug: on a 64-bit system, after 2**32 requests,
  if Xlib notices that 2**16 requests have passed without a response
  from the server, its attempt to sync will infinitely recurse. So it
  crashes when it runs out of stack space.

- Xlib has a multi-threaded race condition involving XAllocID.

  This race applies with or without XCB, and with or without the new
  patches. However, it can only affect applications which call Xlib from
  more than one thread concurrently, and I'm aware of about a half dozen
  of those worldwide. This bug is much more likely to show up when Xlib
  is built using XCB. We're currently exploring ideas for fixing it.

- After running out of its initial allocation of XIDs, XCB assert-fails.

  We found and fixed this bug. Our new code assert()ed something that
  wasn't true. Our next patchset will have the corrected code.

  Since it takes a long time to run out of two million XIDs in normal
  usage, I don't feel the new patches are urgent.

Jamey


signature.asc
Description: Digital signature

Re: [Xcb] [RFC PATCH] New XCB socket handoff mechanism for Xlib/XCB and other libraries

[Jamey Sharp]

On Sat, Mar 15, 2008 at 09:36:37PM -0700, Jamey Sharp wrote:
> The attached patch to Xlib/XCB converts it to use the new handoff
> mechanism. 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.

Note that if you apply this patch to something other than current Git
master of libX11, you will also need the sync fix from Git commit
64325f38bab082a8e0e9ce779a8e582de5c8588e.  You can find the patch at
.

- Josh Triplett and Jamey Sharp


signature.asc
Description: Digital signature

Re: [Xcb] [RFC PATCH] New XCB socket handoff mechanism for Xlib/XCB and other libraries

[Jamey Sharp]

On Sun, Mar 16, 2008 at 06:55:23AM +0100, Vincent Torri wrote:
> it's too complicated for me, so i just have a small (and maybe stupid) 
> question: will it break abi ?

The short answer is "no, this does not break API or ABI", but the
details are a bit tricky.

These patches do not break the API or ABI of libxcb; they do introduce
new interfaces, so new programs built against the libxcb will require
the new libxcb at runtime, but old applications built against libxcb
will continue to work.

However, the patches remove libxcb-xlib and xcbxlib.h entirely, since
they existed solely to provide access to the old Xlib-specific
interface.  Anything depending on libxcb-xlib will have to switch to the
new handoff interface.  To the best of our knowledge, only Xlib links to
libxcb-xlib, and the patches convert Xlib to the new interface;
certainly nothing else *should* have used libxcb-xlib.

Unfortunately, Xlib and XCB must be upgraded at the same time. Though we
tried, we believe the libxcb-xlib interface cannot be implemented on top
of the new handoff system, at least not without reintroducing into
libxcb something like the xcb-xlib lock that we worked so hard to
remove.

However, shared library versioning should prevent any silent failures if
you don't upgrade simultaneously.  New Xlib/XCB will neither build nor
run without new XCB.  If you install new libxcb and remove the old
libxcb-xlib, Xlib will fail to load.  If you install new libxcb and
leave the old libxcb-xlib around, libxcb-xlib should fail to load due to
missing symbols.  In all cases, if you get this wrong, you'll know it,
because you'll get a dynamic linker error.

Distribution packages can address this problem through the use of
dependencies and conflicts, to ensure that the two libraries upgrade
simultaneously.  Make the new libxcb package conflict with the old
libxcb-xlib package.

As for the sentiment of "complicated", please do let us know if you have
any concerns or if you believe it needs a more detailed explanation.  We
found that the new interface simplified implementation in both Xlib and
XCB.

- Jamey Sharp and Josh Triplett


signature.asc
Description: Digital signature