Glibc 2.34 Adds "_Fork" Function Ahead Of Future POSIX Revision

The GNU C Library (Glibc) has landed its _Fork function implementation as an async-signal-safe fork replacement that is also expected to be made part of the next POSIX standards revision.

Going back to 2007 has been Glibc Bug 4737 of the fork function not being signal safe with glibc, unlike some BSDs and other platforms. Various developers have commented on it over the years due to deadlocks occurring in their programs such as if using fork() within a signal handler and other conditions met.

While last year Glibc finally made progress in making their fork function async-signal-safe, that only applies to single-threaded processes. But with the Austin Group that is behind POSIX dropping the async-signal-safe requirement from fork and instead going with the safe _Fork replacement, Glibc is finally getting around to implementing their recommendation.

Within this ticket for the Austin Group bugs the matter was already talked about last decade:

The _Fork() function shall be equivalent to fork(), except that fork handlers established by means of the pthread_atfork() function shall not be called and _Fork() shall be async-signal-safe.

Now finally merged today mid-way through 2021 is Glibc's _Fork support. This _Fork patch by Linaro's Adhemerval Zanella will in turn be with the Glibc 2.34 release for those needing an async-signal-safe fork on Linux and other Glibc-supported environments.