libgpg-error t-lock-single-posix failure on Hurd (was: libgpg-error t-printf test fails on powerpc and ppc64)

[NIIBE Yutaka]

Samuel Thibault <sthibault at debian.org> wrote:
> Wow, I didn't know that glibc made __libc_single_threaded public.
>
> So we'd really rather just fix the value in glibc to just fix the issue
> for real and all applications, rather than work around it in this
> library, and let other libraries only perhaps work around it too.  (The
> fact that there is a thread for signals does not have effect on the
> application-seen behavior).
>
> Just wondering: which error did you actually get? __libc_single_threaded
> being 0 does not guarantee that there are several threads, even on
> Linux.

I know that it's not guaranteed.

			*	*	*

The problem here is a bit historical (and a kind of minor issue for
GnuPG now), we wanted to support the use case of single threaded
application with libgpg-error, with no thread library.

The idea is: libgpg-error can be used both of single threaded and multi
threaded applications.  libgpg-error offers I/O features by "estream"
functions.  And when an application is single threaded, serialization by
mutex is skipped within libgpg-error.


With not-so-modern GNU C library (<= 2.33, IIUC), when an application is
linked with no -lpthread, libgpg-error runtime was able to know it's single
threaded by checking a weak symbol of pthread_cancel.

With modern GNU C library, for GNU/Linux, libgpg-error runtime tries to
detect by __libc_single_threaded.
--