[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7073: no pthread_spinlock_t on Mac OS 10.6.4

From: Paul Eggert
Subject: bug#7073: no pthread_spinlock_t on Mac OS 10.6.4
Date: Tue, 21 Sep 2010 10:23:10 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Thunderbird/3.0.8

On 09/21/10 03:43, Bruno Haible wrote:
> The modules 'lock', 'tls',
> etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
> Basically, every piece of code that wants to provide multithreaded
> access to a global variable (may it be a registry or cache or anything)
> needs locking.

Yes, but the problem is that coreutils does not need and does not want
that multithreaded access, and yet it has to build the multithreaded
support anyway.  The runtime cost is probably small, but it introduces
dependencies and porting problems that are not worth the hassle.  And
I worry that it may cause unreliability at runtime, on some platforms.

It'd be better if applications could say "I don't need gnulib to be
multithread-safe, and please don't bother with thread-safety"
when it incorporates library code from gnulib.  Even 'sort', the only
coreutils program that is multithreaded, doesn't need the gnulib code
itself to be thread-safe.

>> +   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])
> It would be wise to include <pthread.h> here. Not all systems define
> these types in <sys/types.h>; some (e.g. mingw pthreads-win32) require
> a #include <pthread.h>. This include is not part of AC_INCLUDES_DEFAULT.

Thanks, I'll incorporate the following further patch in my next suggestion.
I don't think this'll affect Gary's problem.

--- old/m4/pthread.m4   2010-09-21 00:25:57.628643000 -0700
+++ new/m4/pthread.m4   2010-09-21 10:03:50.638754000 -0700
@@ -15,7 +15,11 @@ AC_DEFUN([gl_PTHREAD_CHECK],
-   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t])
+   AC_CHECK_TYPES([pthread_t, pthread_spinlock_t], [], [],
+      #if HAVE_PTHREAD_H
+       #include <pthread.h>
+      #endif]])
    if test $ac_cv_type_pthread_t != yes; then

reply via email to

[Prev in Thread] Current Thread [Next in Thread]