fork: document _Fork as POSIX 2024

[emaste]

Summary

Reported by: kib

---

I see value in listing _Fork as -2024 so that developers understand whether it's portable. I'm not really sure what we should do with all other existing functions and syscalls -- it's probably most correct to list everything (that is in 2024) as conforms to -2024, with HISTORY describing when things were introduced -- i.e., what this page will look like after this change.

We can look at a holistic update to STANDARDS and HISTORY for libsys and libc at some point.

[imp]

I generally agree: First standard they conform to suffices. Unless there's changes in newer standards that require code changes, then listing those, like we do here is good.

lib/libsys/fork.2

268

Does this need to be reworked? Most people don't know the Austin Group.
We can likely eliminate that sentence entirely since we also don't list the history of changes in behavior (though this one might be big/important enough to do so).
If so, I'd add

The
.Fn fork
function became async-signal safe in
.Fx 13.1 .

[emaste]

lib/libsys/fork.2

268

That's not correct though? fork is not async-signal-safe in all versions, before and after 13.1. 49ad342cc10cba14b3a40ba26cf8bb2150e2925a introduced _Fork which is async-signal-safe.

@kib's commit message:

Current POSIX standard requires fork() to be async-signal safe.  Neither
our implementation, nor implementations in other operating systems are,
and practically it is impossible to make fork() async-signal safe without
too much efforts.  Also, that would put undue requirement that all atfork
handlers should be async-signal safe as well, which contradicts its main
use.

As result, Austin Group dropped the requirement, and added a new function
_Fork() that should be async-signal safe, but it does not call atfork
handlers.  Basically, _Fork() can be implemented as a raw syscall.

Release of glibc 2.34 added _Fork(), do the same for FreeBSD.
Clarify threading behavior for fork() in the manpage.

[emaste]

remove some HISTORY suggested by @imp

[imp]

Looks good

[kib]

My feeling is that it is strange to claim that fork is 2024. It costs nothing to say there specifically that it is -p1003.1 (might be even -88, but I do not have the text).

[kib]

In D47588#1085785, @kib wrote:

My feeling is that it is strange to claim that fork is 2024. It costs nothing to say there specifically that it is -p1003.1 (might be even -88, but I do not have the text).

I changed my mind, stating that fork() conforms to 2004 means that all new requirements like atfork handlers, are met. So it is strange on the first look but non-trivial and useful statement.