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.
