Eric Blake wrote: > for a single-threaded application, having strerror_r call strerror without > locking is just fine, so the mere use of just the 'strerror' module > should not drag in locking. strerror_r only needs locking if it is used > in a multi-threaded application.
The first step in this direction would be to use change the default choice of the locking to "no" in the application's configure.ac, as indicated in <http://lists.gnu.org/archive/html/bug-gnulib/2010-09/msg00410.html> > That means that strerror-impl.h, strerror_r.c, and strerror_r.m4 will > still be needed, but it would get rid of the three glthread files. If people are not satisfied with having the multithread support turned off by default, and want it turned off always, then we should consider adding an option --force-disable-threads to gnulib-tool. I haven't yet thought about how this option makes its effects on the module descriptions. > I would really like to make strerror_r's use of locking > conditional on whether 'lock' is independently present. I understand the wish, but - By default, gnulib should be as multithreaded as possible. Why? Because guaranteeing singlethreaded-ness is something the gnulib-tool user needs to do explicitly. - I would find it harder to achieve the desired behaviour with --avoid=lock than with a new specific option --force-disable-threads. Bruno -- In memoriam Georges Darboy <http://en.wikipedia.org/wiki/Georges_Darboy>
