Bruno Haible <[EMAIL PROTECTED]> wrote: > Eric Blake wrote: >> Next I'm wondering if we should add a module which invokes >> gl_DISABLE_THREADS, as well as pulls in the unlocked-io module, for the >> benefit of projects that are known to be single-threaded, as it is >> slightly easier to add a module to the list of imports than it is to >> modify configure.ac to manually invoke gl_DISABLE_THREADS. > > I don't think this would be a good idea, precisely because it is so easy, > and because importing extra modules from gnulib otherwise is a no-brainer. > But the decision whether to use gl_DISABLE_THREADS must be a conscious one. > For example, if coreutils/src/sort.c becomes multithreaded, coreutils cannot > use this macro.
Yep. And it couldn't use the unlocked-io module, either. That has made me consider (if/when sort does become multithreaded) building specified multithreaded programs in coreutils against a separate thread-safe gnulib instance, so that the remaining 100 programs don't suffer just because sort flipped the MT switch.
