Re: threadlib and emacs

[Bruno Haible]

Paul,

> > I suppose another possible hack is to replace the ifdef with
> > something like m4_ifdef([gl_[]THREADLIB], ...); I haven't
> > investigated that.
> 
> I tried that, and it seems to work.  It strikes me that
> other gnulib macros play the m4_ifdef trick too, e.g.,
> gl_FUNC_WRITE does m4_ifdef([gl_NONBLOCKING_IO], ...).
> Perhaps they also need to obfuscate their symbol too?
> If not, what's a good rule of thumb for deciding whether
> symbols need obfuscating to escape aclocal's attention?

I think we need to hide from 'aclocal' only those identifiers that
occur in .m4 files installed publicly, such as through gettext.

> Anyway, getting back to to the main topic, here is a combined
> patch that doesn't involve altering gnulib-tool.

Still, it does not address the points 1) and 2) of
<http://lists.gnu.org/archive/html/bug-gnulib/2011-07/msg00256.html>.
Therefore I still object to it.

> since it changes pthread_sigmask to work
> even when threadlib is absent, it removes the dependency of
> pthread_sigmask on threadlib.

But that is wrong. If someone wants to use pselect() in a library, that
library may be linked into multithreaded programs. With your patch, the
package that provides the library and blindly requests 'pselect' will get
a pselect() emulation that is not multithread-safe. Whereas in the current
situation, the pselect() emulation will be multithread-safe by default.
And the package maintainer can make the *conscious* decision to use
gl_THREADLIB_DEFAULT_NO and in consequence build a not multithread-safe
library.

Bruno
-- 
In memoriam Jane Haining <http://en.wikipedia.org/wiki/Jane_Haining> 
<http://www.shoah.dk/Courage/Haining.htm>