[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] * configure.ac: Avoid gnulib's test for pthread_sigmask
From: |
Alex Gramiak |
Subject: |
Re: [PATCH] * configure.ac: Avoid gnulib's test for pthread_sigmask |
Date: |
Thu, 02 May 2019 23:48:06 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Paul Eggert <address@hidden> writes:
> On 5/2/19 4:09 PM, Alex Gramiak wrote:
>> The nearby comment states "Avoid gnulib's test for pthread_sigmask", but
>> the method used doesn't seem to work.
>>
>> What I see is that gl_INIT is called, which calls
>> gl_FUNC_PTHREAD_SIGMASK.
>
> It what sense is it not working? gl_FUNC_PTHREAD_SIGMASK is not the same
> as "gnulib's test for pthread_sigmask", so the comment is not
> contradicted by the fact that gl_INIT calls gl_FUNC_PTHREAD_SIGMASK.
Ah, I get it now; it's referring to the AC_CHECK_FUNCS_ONCE in
pthread_sigmask.m4 rather than the tests for pthread_sigmask
functionality.
Is there a reason to test for it in configure.ac instead of in
pthread_sigmask.m4? I would think that it makes sense to use gnulib's
version since it uses AC_CHECK_FUNCS_ONCE over AC_CHECK_FUNCS.
> The latter macro does some useful sanity checking on platforms where
> pthread_sigmask exists but doesn't do anything, e.g., on Solaris 11
> Update 3 or older if you don't define _REENTRANT then Emacs's
> pthreaded code will likely fail in subtle ways (see
> <https://blogs.oracle.com/solaris/mtreentrant-v2>).
Thanks, I understand now. However, considering that the pthread_sigmask
tests are relatively slow, is there an easy way to specify some common
platforms that don't have this problem so that they can skip the tests?