regression in X11R7.2?

Jack Howarth howarth at
Wed Nov 21 12:31:47 PST 2007

   Currently the modified SRPM I created for xview with the
XAllocIDs() change are available for Fedora on...

If you see anything thing else in the xview source code
that will likely break with future changes to, please
let me know about them and how we might fix them. There
is a critical NMR software program (NMRDraw of NMRPipe)
which uses xview so I am trying to keep it functional as
long as possible. The joys of using prehistoric code.

On Wed, Nov 21, 2007 at 12:06:01PM -0800, Jamey Sharp wrote:
> In this case, XView really was broken, though. XAllocID was never safe
> to be called multiple times without issuing a request after each call.
> Before XCB, calling XAllocID multiple times would have worked most of
> the time, but would have failed whenever the client ran out of its batch
> of IDs. With XCB, the second and later calls will always fail, until the
> SyncHandle macro is invoked.
> Anyway, using XAllocIDs is clearer, and will work with all versions of
> Xlib. I hope that patch is accepted.
> (OMG, I had no idea XAllocID is public in Xlib.h. It totally isn't
> thread-safe and makes all sorts of assumptions about how it's called,
> and it isn't documented.)
> I made the mistake of reading libxview source while trying to answer
> this mail. It seems to be in the classic tradition of layers of bad code
> built upon more bad code, starting with Xlib. This particular bit should
> have just used Xlib's atom cache rather than building its own, and
> should have done just about anything besides using XSaveContext to
> associate types and private data with atoms. Then it wouldn't have to
> allocate XIDs for a strictly client-side resource. </rant>
> Heh, yeah, that works eventually. :-)
> Jamey
> Version: GnuPG v1.4.6 (GNU/Linux)
> iD8DBQFHRI+gp1aplQ4I9mURAt9qAJ9AjKhqlwqeMysT+1CfKMOxPh0RhgCePaZy
> EuTTYaCfQkyp9+8qFbnhNXw=
> =XkEP

More information about the xorg mailing list