Re: hard_locale in a single-threaded app

[Bruno Haible]

Paul Eggert wrote:
> > In detail, we have dependency chains
> >   exclude -> regex -> lock -> once -> pthread-once
> >   nstrftime -> localename-unsafe-limited -> getlocalename_l-simple -> lock 
> > -> once -> pthread-once
> >   regex -> lock -> once -> pthread-once
> > 
> > Here, in fact, the dependency chain
> >   localename-unsafe-limited -> getlocalename_l-simple -> lock
> > can be reduced
> 
> Thanks for doing that. I hope that diffutils's existing use of 
> GNULIB_EXCLUDE_SINGLE_THREAD and GNULIB_REGEX_SINGLE_THREAD are enough 
> to break the other chains.

These flags don't break dependency chains at the module level. They
optimize the code, despite of the dependencies.

> > * Omitting any multithreading code. Users can already force it by 
> > configuring
> >   with --disable-threads. As a package maintainer, you can make this the
> >   default by adding this line to configure.ac:
> >     AC_DEFUN([gl_THREADLIB_DEFAULT_NO], [])
> 
> Shouldn't this be documented in doc/multithread.texi? At least to 
> clarify the relationship between it and GNULIB_EXCLUDE_SINGLE_THREAD etc.

I'm OK to document it, once you have made sure that it works as intended :)
Because it has not been sensibly tested so far.

> Also, since it's checked via m4_ifdef, shouldn't it be defined via 
> m4_define([gl_THREADLIB_DEFAULT_NO])?

Since an AC_DEFUN results in an m4-level definition, either AC_DEFUN or
m4_define would likely work. In the documentation, I would prefer AC_DEFUN,
since m4_define is more "exotic" for most configure.ac maintainers.

> It's not simply shrinking the tarball's size. It's making it easier for 
> diffutils developers and builders to see that multithreading need not be 
> worried about

Such a statement is important, yes: The omnipresent use of global and
'static' variables is only possible when multithreading is not an issue.
But isn't the best way to formulate this statement a sentence in the
HACKING file?

> Even if from Gnulib's viewpoint it's 
> simpler to leave the multithreaded source code and tests in, from the 
> consumer's viewpoint it may well be simpler to omit that stuff when the 
> package can't significantly benefit from multithreading.

Maybe the easiest way to bridge the two viewpoints is that, at the end
of running 'bootstrap', you have a command that removes selected files
from the lib/ directory? The bootstrap_post_import_hook and bootstrap_epilogue
functions are good candidates, IMO.

Bruno