[Xcb] Patches to build X11 w/ XCB on Sol

[Travis Spencer]

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
> program. 

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
reason.

> 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_init(&attr);
> 	pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
> 	pthread_mutex_init(&XCBConnectionOfDisplay(dpy)->iolock, &attr);
> 	pthread_mutexattr_destroy(&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?

-- 

Regards,

Travis Spencer
-------------- next part --------------
Index: xcl/xcblock.c
===================================================================
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. */
 
+#ifdef __GLIBC__
 #define _GNU_SOURCE /* for PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP */
 #include <features.h>
+#endif
 
 #include "Xlibint.h"
@@ -48,6 +50,14 @@
 int _XInitDisplayLock(Display *dpy)
 {
+#ifdef PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
     pthread_mutex_t lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
     XCBConnectionOfDisplay(dpy)->iolock = lock;
+#else
+    pthread_mutexattr_t attr;
+    pthread_mutexattr_init(&attr);
+    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
+    pthread_mutex_init(&XCBConnectionOfDisplay(dpy)->iolock, &attr);
+    pthread_mutexattr_destroy(&attr);
+#endif
 
     dpy->lock_fns = (struct _XLockPtrs*)Xmalloc(sizeof(struct _XLockPtrs));