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

[phoronix]

Phoronix: 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...

https://www.phoronix.com/scan.php?page=news_item&px=Glibc-Adds_Fork

[coder]

This represents a major missed opportunity not to call it spoon()!

[MaxToTheMax]

More gratuitous underscores all over everything. I'm bummed. I'd rather fork() was just fixed.

[hsci]

Maybe ABI- or Bug-Level compatibility?

[uid313]

Oh so this is one thing where BSD is better than Linux.

[jabl]

Oh so this is one thing where BSD is better than Linux.

As mentioned, the problem is that even if fork() were to be AS-safe, a programmer might not be aware or able to control what various libraries are doing in their pthread_atfork() handlers. So if they do something AS-unsafe, you're back to square one anyway. So _Fork(), ugly name notwithstanding, is a more robust solution for the problem of how use fork in a signal handler.

Besides, on Linux one should be using signalfd rather than messing around with signal handlers and worrying about AS-safety anyway.

[bregma]

Whatever happened to the async-signal-safe `posix_spawn()` call that already does the right thing and is already in POSIX?

[skeevy420]

Well fork me running.

[cmsigler]

This represents a major missed opportunity not to call it spoon()!

SPOON!

[milkylainen]

I would vote for the missed opportunity to go all camelcase unreadable batshit crazy on the function name.
This half-assed _Fork is very meh.

__F0rK_n0t_ASYNCSH1tZ!__

Then we could all vote for rewriting Glibc in Java or something useful when we're already doing unreadable.