It is not vfork, it is similar to rfork in FreeBSD but note that fork(), vfork(), and __clone() all invoke clone() in Linux post 2.4. The costs of copying the parent tables and creating the task is the only additional cost for fork(), which is very different than the didactic explanation of fork()+exec().

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)."

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

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.