Re: threadlib and emacs

[Paul Eggert]

On 07/18/11 17:38, Bruno Haible wrote:
> [the new patch] does not address the points 1) and 2) of
> <http://lists.gnu.org/archive/html/bug-gnulib/2011-07/msg00256.html>.

That comment's point (1a) is the claim that some more-complicated and
not-yet-implemented approach would be better.  Perhaps it would be;
but it does not mean that the patch I've proposed (which is simple and
which works for Emacs), is worse than what we have already (which does
not work for Emacs).

That comment's point (1b) was addressed in the the more recent patch,
as it does not use gl_AVOID_MODULE_x.

That comment's point (2) is the claim that the changes are useful only
for Emacs.  I've written about that claim at some length.  You don't
agree with my assessment, but that does not mean that I didn't address
the point.

Gnulib should be flexible enough to support different styles of usage
with a minimum of overhead and complexity.  It shouldn't insist on a
particular programming model.  It's fine that Gnulib supports
threadlib, but Gnulib shouldn't insist on threadlib as opposed to
POSIX threads.

> coreutils-8.12 contains threadlib.m4 and invokes gl_THREADLIB
> from configure. I haven't seen reports that it is causing harm.

As I understand it, coreutils drags in threadlib only by accident (for
the tests) and threadlib is not used in the coreutils applications
proper.  If we could break unnecessary dependencies (a common problem
with gnulib, unfortunately, and not just for threads), coreutils
wouldn't use threadlib at all.

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

That's a good point.  So let's omit that patch's change to the
dependencies (in modules/pthread_sigmask).  That is, Emacs etc. can
use --avoid=threadlib; the default can continue to drag in threadlib.

Surely this removes your major objection to the patch.  The revised
patch won't change behavior at all, unless an application explicitly
says --avoid=threadlib.

> many applications make use of POSIX threads, without
> using gnulib, or using gnulib but not threadlib.m4. But they do
> so at the price of
>   - having lots of platform dependent code (gcc), or
>   - turning off POSIX threads on some older platforms (coreutils
>     'sort', for example), or
>   - having portability bugs.

It's the second category we're talking about here.

> I don't really understand your objections against threadlib.m4,
> outside of Emacs. Of course it is not simple code, but is that
> enough of an argument to discard it entirely?

Yes, I'm afraid so.  I'd rather not take the time to understand
another thread library interface, support it in applications I help
maintain, and explain it to others.

POSIX threads are not perfect, but they're part of a standard
interface that is reasonably well understood and they are good enough
for many applications.  Gnulib by-and-large supports a POSIX interface
in other areas, without having to add in a higher-level gnulib-only
API and support library.  There's no fundamental reason it can't do
the same thing for simple things like pselect.

> I don't see coreutils - with a modern autoconf infrastructure - and
> emacs - with a case-by-case configure.in - in the same boat here, at all.

In some ways they are different, yes.  The sense that I was talking
about is that they both use just POSIX threads, and do not need
porting to Solaris threads etc.  Also, for both packages it's unlikely
that I could convince their maintainers to use a non-POSIX thread
interface even if I thought it was a good idea.