bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 03/10] pthread_sigmask: new module


From: Bruno Haible
Subject: Re: [PATCH 03/10] pthread_sigmask: new module
Date: Fri, 8 Jul 2011 23:05:56 +0200
User-agent: KMail/1.9.9

Hi Paul,

> Thanks for that review, and for fixing all those problems.

Oh, it's too early for the thanks: The unit tests still fail on five
platforms, from FreeBSD to Solaris.

> First, there's what appears
> to be a clear typo in the gl_THREADLIB case: it is searching
> for pthread_sigmask in a library, but it's using
> AC_COMPILE_IFELSE.  Surely that should be AC_LINK_IFELSE.

Oops, yes. Clearly a mindo. Thanks for noticing it.

> Second, when gl_THREADLIB is not in use, but the application
> is using pthread_sigmask, the application is most likely using
> POSIX threads, not no threading at all.  This is the case with
> Emacs: on GNU/Linux it almost invariably uses threading, due
> to the libraries that it employs (e.g., GTK3), even though
> Emacs proper is not multithreaded yet.  In this case, Emacs
> should be using pthread_sigmask and not sigprocmask

I agree with the argumentation, but not with the patch:

>    ] ,[
> -    dnl If module 'threadlib' is not in use, assume all programs will be
> -    dnl single-threaded.
> -    if test $ac_cv_func_pthread_sigmask = yes; then
> -      REPLACE_PTHREAD_SIGMASK=1
> -    else
> -      HAVE_PTHREAD_SIGMASK=0
> +    dnl gl_THREADLIB is not in use.  Assume the application wants
> +    dnl POSIX semantics.
> +    if test $ac_cv_func_pthread_sigmask != yes; then
> +      gl_save_LIBS=$LIBS
> +      AC_SEARCH_LIBS([pthread_sigmask], [pthread c_r])
> +      LIBS=$gl_save_LIBS
> +      if test "$ac_cv_search_pthread_sigmask" = no; then
> +        HAVE_PTHREAD_SIGMASK=0
> +      elif test "$ac_cv_search_pthread_sigmask" != 'none required'; then
> +        LIB_PTHREAD_SIGMASK=$ac_cv_search_pthread_sigmask
> +      fi
>      fi
>    ])

This patch tries to do what m4/threadlib.m4 does, and does it incorrectly.
For example, when linking with -lpthread you also need some flags so that
<pthread.h> will be grokked by the compiler:

      # On OSF/1, the compiler needs the flag -pthread or -D_REENTRANT so that
      # it groks <pthread.h>.

There are many more little complications like that.

So I'm in favour of removing the 'else' branch of this
   m4_ifdef([gl_THREADLIB], ...)
invocation, and instead add a module dependency from 'pthread_sigmask' to
'threadlib'.

Bruno
-- 
In memoriam Jean Moulin <http://en.wikipedia.org/wiki/Jean_Moulin>



reply via email to

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