I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad.

The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.

Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...

The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution.

In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c

I was reading this part of kab_DZ collate on glibc and something is not correct :

Link glibc 2.41-6 : https://sources.debian.org/src/glibc/2.41-6/localedata/locales/kab_DZ/

1/…

C++Now 2025 SESSION ANNOUNCEMENT: Using TLA+ to Fix a Very Difficult glibc Bug by Malte Skarupke

https://schedule.cppnow.org/session/2025/using-tla-to-fix-a-very-difficult-glibc-bug/

Register now at https://cppnow.org/registration/

The #Maneage #reproducibility system for scientific research papers that starts from a minimal POSIX-like host OS does not yet build [1] the #GNUCLibrary = #GLibC . We have a draft implementation building glibc *after* #GCC [2]; and an alternative proposal arguing that building glibc *first* and gcc second would be more long-term sustainable [[1] comment18].

Should GLibC be built first? Why (or why not)?

[1] https://savannah.nongnu.org/task/?15390
[2] https://gitlab.com/maneage/project-dev/-/blob/glibc/reproduce/software/make/core-gnu.mk#L718

Interesting things happen, when you attempt building an older version of the #glibc with a recent version of #GCC

https://asciinema.org/a/o5vaV6gvHSq49V3QpjORDfSaR

Who at #glibc do we need to bribe to get @codonell :

"I think we really need to expose some
sort of clone/clone3 wrapper, with some guardrails against unsupportable
scenarios (such as spawning new threads in the current process)."

finally implemented! It really is missing!
https://patchwork.sourceware.org/project/glibc/patch/20230803163558.991832-7-adhemerval.zanella@linaro.org

Ummm

#glibc #libc #programming #binary #opensource

https://jangafx.com/insights/linux-binary-compatibility

Ho, un problème de mise à jour de #glibc avec #Debian unstable. Je crois que ça fait des années que ça ne m'était pas arrivé

Tuning the #glibc memory allocator (for #Postgres) https://vondra.me/posts/tuning-the-glibc-allocator-for-postgres/

Pues ya tengo respuesta, por temas técnicos que no explicare aquí (pues no los entendí del todo, je je) el tiempo de ejecución de #Steam no cubre / alcanza la librería #glibc y lo que son los controladores gráficos. Por eso que al actualizar (principalmente distribuciones de liberación continua) esta librería muchos juegos (nativos principalmente, al parecer) se rompieron.

https://www.gamingonlinux.com/2025/02/the-glibc-2-41-update-has-been-causing-problems-for-linux-gaming/