[Top][All Lists]
[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>
- [PATCH 03/10] pthread_sigmask: new module, Paul Eggert, 2011/07/06
- [PATCH] pthread_sigmask: always replace when not using pthread, Eric Blake, 2011/07/06
- unit tests for sigprocmask, Bruno Haible, 2011/07/07
- Re: [PATCH 03/10] pthread_sigmask: new module, Bruno Haible, 2011/07/07
- Re: [PATCH 03/10] pthread_sigmask: new module, Paul Eggert, 2011/07/08
- Re: [PATCH 03/10] pthread_sigmask: new module,
Bruno Haible <=
- Re: [PATCH 03/10] pthread_sigmask: new module, Paul Eggert, 2011/07/08
- Re: threadlib and emacs, Bruno Haible, 2011/07/08
- Re: threadlib and emacs, Paul Eggert, 2011/07/09
- Re: threadlib and emacs, Bruno Haible, 2011/07/09
- Re: threadlib and emacs, Paul Eggert, 2011/07/09
- Re: threadlib and emacs, Bruno Haible, 2011/07/12
- Re: threadlib and emacs, Paul Eggert, 2011/07/16
- Re: threadlib and emacs, Bruno Haible, 2011/07/17
- Re: threadlib and emacs, Paul Eggert, 2011/07/17
- Re: threadlib and emacs, Paul Eggert, 2011/07/17