Re: threadlib and emacs

[Bruno Haible]

Hi Paul,

> It's not unusual for applications to want to use POSIX threads
> without also wanting to use threadlib.

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

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?

> Coreutils does that too.

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

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

With the module 'threadlib' from gnulib that is easy: gnulib pulls
in the module, and the maintainer only has to ensure that 'tail'
gets linked to $(LIB_PTHREAD_SIGMASK). Note that $(LIB_PTHREAD_SIGMASK), like
$(LIBTHREAD), expands to empty on glibc and Solaris systems. On these
systems with weak symbols support, only the _creation_ of threads
requires linking with -lpthread; that's what the variable $(LIBMULTITHREAD)
is for.

Additionally, threadlib.m4 has a special feature for packages which don't
need multithreading at all:

    If the configure.ac contains a definition of the gl_THREADLIB_DEFAULT_NO
    (it must be placed before the invocation of gl_THREADLIB_EARLY!), then the
    default is 'no', otherwise it is system dependent. In both cases, the user
    can change the choice through the options --enable-threads=choice or
    --disable-threads.

But this doesn't apply to coreutils, since some coreutils programs ('sort')
are multithreaded, and some others (maybe 'factor', maybe 'df') may become
multithreaded as well.

So, on glibc and Solaris, using threadlib will ensure that 'tail' does not
get linked with -lpthread, while 'sort', 'factor', etc. will.

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

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.

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

So far, you have not convinced me.

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

I agree with that, and have agreed that rewriting these 5 modules to
provide a POSIX API on top of the other platform dependent APIs is a
better approach than the current one. (If only I had more time to
realize that refactoring...)

However, this is not a good enough reason to reject threadlib.m4, since
the majority of threadlib.m4 deals with the prerequisites of the POSIX
API. The Solaris threads, Win32 threads, and Pth threads section of
this file are not causing the major complications.

If you want it, we can allow packages also to enforce that threadlib.m4
does not accept any threading choice than 'posix' and 'no'. Like this:

    If the configure.ac contains a definition of the gl_THREADLIB_ONLY_POSIX
    macro (it must be placed before the invocation of gl_THREADLIB_EARLY!),
    then the macros will only look and only accept the choices 'posix' and 'no'.

In a package that uses this macro, you can then be sure that you don't need
to care about Pth, Win32, etc.

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

threadlib's interface is documented in the first 30 lines of
m4/threadlib.m4. As I said in an earlier mail, the replacement
for Emacs can consist of a couple of statements that set
LIBTHREAD, LTLIBTHREAD, LIBMULTITHREAD, LTLIBMULTITHREAD all to
empty and defines USE_POSIX_THREADS if configure.in has "determined"
that POSIX threads should be used.

You don't need to do porting for Windows, Solaris, etc. for that.
You can assume that the people responsible for emacs/configure.in
have already done that.

> The proposed patch is pretty simple, and does that.

But as mentioned, the request is Emacs specific, therefore the patch
belongs in Emacs, not in Gnulib.

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