Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...

... in good old #C!

Well, at least sort of.

* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.

* I can't do anything about the basic language syntax, so some boilerplate comes with using it.

* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)

But then ... async/await in C!

Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html

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

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

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

Making a #Linux #Distro from the #LFN guide by MapleCircuit. (Great guy, search up the series #LinuxfromNothing and go follow him!!!)

I’m using #Musl instead of #Glibc for funsies.

I’m #Nerdy as shit, and that’s pretty cool.

The glibc disaster, Wayland HDR update, and more Linux Gaming News!

https://subscribeto.me/videos/watch/ab8c04fe-8247-4844-88eb-4af189b21c42

Jeżeli kiedyś zastanawialiście się, jak szybko rośnie `packaging.tags.sys_tags()` na GNU / #Linux, to mam formułkę (chyba że coś popieprzyłem). Dla #CPython 3.x na #glibc 2.y, łączną liczbę tagów wyraża wyrażenie:

2xy + x + 3y + 3

Albo równoważnie:

x(2y + 1) + 3y + 3
y(2x + 3) + x + 3

Co za tym idzie, jeżeli nic innego się nie zmienia, to każda nowa wersja Pythona dodaje (2y + 1) tagów, a każda nowa wersja glibc dodaje (2x + 3) tagów. Dla glibc 2.41, daje to 83 nowe tagi na nową wersję CPythona. Dla CPythona 3.13, mamy 29 nowych tagów na nową wersję glibc.

No i dla porównania: CPython 3.13 na architekturze x86_64 z glibc 2.41 ma już 1205 zgodnych tagów paczek wheel.

If you were ever wondering how fast `#packaging.tags.sys_tags()` are growing on GNU / #Linux, I have a formula for you (unless I screwed up the maths). For #CPython 3.x on #glibc 2.y, the total number of tags is:

2xy + x + 3y + 3

Or equivalently:

x(2y + 1) + 3y + 3
y(2x + 3) + x + 3

So all other things equal, every new minor version of #Python introduces (2y + 1) tags, and every new minor version of glibc introduces (2x + 3) tags. For glibc 2.41, this means 83 new tags per CPython version. For CPython 3.13, this means 29 new tags per glibc version.

Oh, and for a good measure: CPython 3.13 on x86_64 with glibc 2.41 features 1205 compatible wheel tags.

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

Using Discord on Arch Linux? Be aware of this issue once you upgrade to glibc 2.41.

#discord #archlinux #arch #glibc #linux #TechNews

https://officialaptivi.wordpress.com/2025/02/04/discord-and-glibc-2-41-update-on-arch-linux/

Discord and glibc 2.41 update on Arch Linux

Discord is an application that enables communication with other people in groups, while building the greatest communities across different guilds. Glibc is a GNU C standard library that provides you with standard C functions for your applications and with wrappers for system calls for your Linux platform.

Recently, the Arch Linux team is planning to push the newly-released glibc 2.41 (released on January 29th, 2025) later today, which provides the following features:

• Glibc on Linux now supports the sched_setattr and sched_getattr functions for parameterized scheduling policies such as SCHED_DEADLINE mode.
• ISO C23 function families in the math.h header file for acospi, asinpi, atan2pi, atanpi, cospi, sinpi, and tanpi.
• Support for the Linux getrandom vDSO.
• Faster strnlen() performance on AMD and Intel CPUs.
• A “_ISOC2Y_SOURCE” feature test macro to enable features from the draft ISO C2Y standard.
• Optimizations and correct rounding for various math functions.
• The new “glibc.rtld.execstack” tunable allows for controlling whether an executable stack is allowed from the main program.
• Support for the extensible Restartable Sequences “RSEQ” ABI since Linux 6.3.
• Character encoding and other tables updated against Unicode 16.0.
• The iconv program now supports converting files in-place.
• The DNS stub resolver now supports the strict-error option.
• Support for Guarded Control Stack (GCS) on AArch64 systems.
• Faster performance for code generation and math function speed on AArch64 systems with SVE and NEON intrinsics.
• A new architecture type to better support Hygon x86_64 processors.
• The Glibc test suite has been expanded significantly with some 800+ more test cases than the prior version.
• Fixing a possible buffer overflow when printing an assertion failure message.
• Many bug fixes.

However, it looks like that it may have caused problems with the stable version of Discord, because when you install the updated glibc, Discord will notify you that the installation is now corrupt. Luckily, it only affects the audio connectivity feature, but for those who rely on this feature, this is unfortunate.

The Discord team have fixed this in canary builds, so it will take time to push the fix to the stable channels one day. Meanwhile, the team advises you to use the Canary version of Discord, the Flatpak version, or the browser version.