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

[linuxgeex]

just like fork from main is flawed because there should be only one main thread?
how would you attach debugger from a signal handler?

Generally speaking it's poor form to fork() from a thread, period. There are hacks to try to work around the problems created by forking from a thread (fork creates a process on a COW copy of the stack of the thread, along with the entire parent process memory, including held mutexes.) A signal handler basically uses a broken kernel implementation of threading (anyone who writes C signal handlers rapidly learns the limitations thereof) and has the exact same issues for fork().

A debugger attaches to a process with the CPU's stepping mode enabled.

[pal666]

Exactly. fork() in a signal handler is 100% always a bug. Only one thread should be responding to a signal. fork()ing creates a second process with a COW stack of that signal handler. That's plain and simply flawed software architecture.

just like fork from main is flawed because there should be only one main thread?

There's no prize for last place in software design.

how would you attach debugger from a signal handler?

[pal666]

More gratuitous underscores all over everything.

names starting with underscore and capital letter are reserved, anything else could be user-defined macro which will break existing programs

I'd rather fork() was just fixed.

it's "fixed" by not running atfork handlers. i'd rather not let you break fork under the pretense of fixing it

[uxmkt]

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

posix_spawn warrants a posix_spawn_file_actions_t structure. Most code just builds it before posix_spawn, but with regard to the bug report, a program would have to build it before even entering the signal handler - which I guess is doable, but people and programs failed to do so.

[linuxgeex]

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.

Exactly. fork() in a signal handler is 100% always a bug. Only one thread should be responding to a signal. fork()ing creates a second process with a COW stack of that signal handler. That's plain and simply flawed software architecture. There's no prize for last place in software design.

[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.

[cmsigler]

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

SPOON!

[skeevy420]

Well fork me running.

[bregma]

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

[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.