[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: single-threaded optimizations
From: |
Bruno Haible |
Subject: |
Re: single-threaded optimizations |
Date: |
Sun, 07 Mar 2021 10:58:28 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-203-generic; KDE/5.18.0; x86_64; ; ) |
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