emacs-devel
[Top][All Lists]
Advanced

[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?



reply via email to

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