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

[Paul Eggert]

On 07/08/11 14:05, Bruno Haible wrote:

> 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'.

The 'threadlib' module is pretty heavyweight, though.  I want to
avoid complicating 'configure', or 'src/config.in', because big
changes for various reasons are not that easy to merge into Emacs.
I'd rather have something simple, even if it doesn't port to older
POSIXish platforms.

For example, it's fine if pthread_sigmask-without-threadlib
refuses to use OSF/1 pthread_sigmask due to incompatibilities
or to compiler hassles.  The worst that can happen is that Emacs
will fall back on sigprocmask, which is what it's using now;
and likely that is good enough, since I expect that Emacs
is single-threaded on OSF/1.

I looked at the current non-threadlib implementation again in the light of your
comments, and I now think that it goes too far, as it fusses with
LIBS and so forth.  I'd rather have something even simpler.

I see that you're now working in that area, but
once things have settled down, I'd like to essay something that
just tries a POSIX.1-2008 signature without messing with
compiler or linker flags, and gives up if that doesn't work.
The idea is that if gnulib-without-threadlib needs to do anything
special to get pthread_sigmask to work (over and above what the
application has already done), then it doesn't bother.  The hope is that
this would address the OSF/1 problem by rejecting its implementation
unless Emacs already, for other reasons, has specified the proper
compiler and linker flags for it.