Re: threadlib and emacs

[Paul Eggert]

On 07/17/11 15:10, Bruno Haible wrote:

> the changes are ONLY useful for Emacs.

No, they are useful for other packages too.  It's not
unusual for applications to want to use POSIX threads
without also wanting to use threadlib.  Coreutils does
that too.

For example, suppose we wanted to improve the timestamp
resolution of coreutils 'tail' by having it use 'pselect'
rather than 'select', if 'pselect' is available.  That's not
a high-priority task, but it's a reasonable thing to do.
Coreutils shouldn't have to drag in threadlib to do that.
And whatever mechanism that coreutils uses, should also be
used by Emacs, because the two applications are in the same
boat here.

It's reasonable to think that other applications, besides
Emacs and coreutils, might also want to use pselect without
dragging in threadlib.

>   there is not only the 'pthread_sigmask' module that depends on it,
>    but also
>      lock
>      tls
>      cond
>      thread
>      yield
>      gettext
>    This is a maintenance problem.

No doubt it is, but programs should be able to assume and
use the POSIX thread model without having to use wrappers.
To the extent that gnulib can support that for simpler primitives like
pselect, that's a win.  If gnulib can't also support that for
more-complicated needs, that's too bad, but it doesn't mean
that using a POSIX interface is not a win when we can get it.

>    It will make maintenance easier if you provide a
>    replacement for 'threadlib' that obeys the same
>    interface as threadlib (i.e. its m4 macros set the same
>    AC_SUBSTed variables).

That might do the trick, but it sounds like a lot of work.
I don't understand threadlib's interface and m4 macros and
would rather not invest a lot of time in porting to Windows
and Solaris threads and etc. if I don't have to, which I
don't.  All that's needed here is something that works and
gives apps POSIX primitives that are easily doable.  The
proposed patch is pretty simple, and does that.

> 1b) I understand that the use of gl_AVOID_MODULE_x is to avoid a problem
> of the previous approach: m4_ifdef([gl_THREADLIB], ...) did not work
> because gettext had installed a copy of threadlib.m4 in 
> $PREFIX/share/aclocal/.
> But it still smells the workaround hack (it makes a semantic difference
> between a module that is absent and a module that is avoided).

Give the problems with the way aclocal works, some sort of
hack seems inevitable.  The application writer must have a
way of controlling which gnulib modules is being used.

I suppose another possible hack is to replace the ifdef with
something like m4_ifdef([gl_[]THREADLIB], ...); I haven't
investigated that.

> LIBS and CPPLAGS are fixed in emacs/configure.in. This is a "database of
> options per platform" approach

Yes, that is a problem with Emacs, but it's relatively
independent of this issue.  In this sense coreutils and
Emacs are quite different.  Coreutils (and I imagine other
applications) can want to use POSIX threads, without
involving the "database of options per platform" approach.