Re: single-threaded optimizations

[Bruno Haible <bruno@clisp.org>]

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