Hi Paul, > > a general macro won't cut it e.g. for coreutils. coreutils > > has multithreaded programs ('sort') next to single-threaded programs. > > But coreutils wants to optimize wcwidth. GNULIB_WCHAR_SINGLE actually > > means "assume that the locale has been set before the program becomes > > multithreaded, and won't change afterwards". Similarly, > > '#include "unlocked-io.h"' does not mean that the program is single- > > threaded; it means that no FILE object is being accessed in more than > > one thread. > > Good point. How about this idea? > > * We establish a new macro GNULIB_MBTOWC_SINGLE which means "assume that > at most one thread invokes mbtowc-like functions". The mbtowc > replacement uses this instead of using USE_UNLOCKED_IO. Tar can #define > this new macro.
I like this idea. The packages can then define or not define each such macro individually. > * If macros like GNLIB_MBTOWC_SINGLE proliferate, we can have a single > macro GNULIB_SINGLE_THREADED that implies all the other macros. For now > I'm not sure it's worth the bother to do this. I agree, it doesn't seem worth to have such a GNULIB_SINGLE_THREADED macro because - more code becomes multithreaded over time, - the documentation clearly states what each of the individual macros imply. > * If someone has the time, fix the underlying problem that the Gnulib > mbrtowc replacement doesn't link under AIX in some circumstances, unless > you #define GNULIB_MBTOWC_SINGLE. The mbrtowc modules states: Link: $(LIB_MBRTOWC) This link dependency (which expands to -lpthread on AIX) is needed because we document that This function does not put the state into non-initial state when parsing an incomplete multibyte character on some platforms: AIX 7.2. and - Since the state of mbrtowc is hidden, we cannot work around this without reimplementing mbrtowc from scratch. - Since the wide character representation on AIX is locale dependent and undocumented, we cannot roll our own mbrtowc implementation, but must use mbtowc(). - mbtowc() uses global state and is therefore not multithread-safe. > I think I > might want to investigate the possibility of having the mbrtowc > replacement use AIX mbrtowc instead of a lock around AIX mbtowc, as that > should perform better anyway. But I'm not sure AIX is worth the time for > this sort of thing. I don't know what the solution could look like. Bruno