If you look in the glibc source code in `sysdeps/unix/sysv/linux/arch-fork.h` you will see how it is calling clone BTW.
In Linux really threads are just tasks that share memory and processes are tasks that do not.
fork() and pthread_create() simply end up in the same place because user threads or processes are just tasks to the kernel.
Kernel threads, which are not user space are different.
https://github.com/torvalds/linux/blob/master/include/linux/...
The sched wouldn't be able to use a Red-Black trees in the way it does if it didn't
Re:System CPU Usage and Glibc
by AshamedCaptain on Friday August 20, 2021 @05:48AM
(#28244364)
So there is no change in visible behavior, it is just an implementation detail.
A very important implementation detail if you are digging into the kernel due to performance problems like in the OP.
But yes, in the naive user perspective case the contract hasn't been violated.
https://man7.org/linux/man-pages/man2/fork.2.html
"C library/kernel differences Since version 2.3.3, rather than invoking the kernel's fork() system call, the glibc fork() wrapper that is provided as part of the NPTL threading implementation invokes clone(2) with flags that provide the same effect as the traditional system call. (A call to fork() is equivalent to a call to clone(2) specifying flags as just SIGCHLD.) The glibc wrapper invokes any fork handlers that have been established using pthread_atfork(3)."