[Xcb] Patches to build X11 w/ XCB on Sol
tspencer at cs.pdx.edu
Sat May 14 23:30:30 PDT 2005
On Sun, Apr 03, 2005 at 12:52:01PM -0700, Jamey Sharp wrote:
> > 3) PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP was unsupported.
> > The third problem is probably no surprise; we talked about it a little
> > on Friday. I'm not sure if my fix is correct, so make sure and have a
> > good look at it. I don't know much about threads, but I surfed around
> > and concluded that using PTHREAD_MUTEX_INITIALIZER when
> > PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP isn't available is an OK thing
> > to do.
> I'm pretty sure it isn't OK, but you can test it with the attached
OK. I tested it. It didn't work. I used your suggestions below, and
got it working.
> If the program halts (which it's supposed to do quickly) then
> your patch is fine.
With the new modifications, it halts straight away.
> If it hangs, we'll have to do something else. You
> need to make sure libpthread is linked in or the test won't be valid;
> the command I used is:
> gcc -Wall -lX11 -lpthread rec-lock.c -o rec-lock
I didn't need libpthread but I needed libnsl and libsocket for some
> However, the fix is pretty easy. The _NP in the initializer name
> indicates a "non-portable" extension, but we had a plan to implement a
> more portable alternative where needed. On systems supporting the UNIX98
> standard, which quick inspection reveals includes Solaris, the first two
> lines of _XInitDisplayLock can be replaced with this code (untested, but
> I think correct):
> pthread_mutexattr_t attr;
> pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
> pthread_mutex_init(&XCBConnectionOfDisplay(dpy)->iolock, &attr);
> The reason we don't want to do this on Linux is that the
> pthread_mutexattr functions are only available if you link against
> libpthread, which the majority of Xlib apps don't need and so kind of
> don't want. It doesn't look to me like Solaris has the same problem,
> though, so we should be in good shape there.
What was that function that you were talken about last Wednesday that
can be used to determine at runtime if a program is linked against a
libpthread? Was it dlopen(3DL)?
Should I make a bug report on freedesktop or will you or someone else
around here review and commit it?
-------------- next part --------------
RCS file: /cvs/xlibs/X11/src/xcl/xcblock.c,v
retrieving revision 1.11
diff -c -w -f -u -2 -r1.11 xcblock.c
--- xcl/xcblock.c 6 Apr 2005 01:14:30 -0000 1.11
+++ xcl/xcblock.c 15 May 2005 06:29:08 -0000
@@ -2,6 +2,8 @@
* This file is licensed under the MIT license. See the file COPYING. */
#define _GNU_SOURCE /* for PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP */
@@ -48,6 +50,14 @@
int _XInitDisplayLock(Display *dpy)
pthread_mutex_t lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
XCBConnectionOfDisplay(dpy)->iolock = lock;
+ pthread_mutexattr_t attr;
+ pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
+ pthread_mutex_init(&XCBConnectionOfDisplay(dpy)->iolock, &attr);
dpy->lock_fns = (struct _XLockPtrs*)Xmalloc(sizeof(struct _XLockPtrs));
More information about the xcb