> He's saying that MAP_PRIVATE|MAP_ANONYMOUS causes copy-on-write not just for forked processes

But that is just plain wrong; it's practically in the definition of threads that they share the VM between themselves. If MAP_PRIVATE meant "copy-on-write even for threads using std::vector" most multi-threaded programs would stop working, save for perhaps a couple of purely functional examples.

On the positive side, there wouldn't be any data-races. :)

If you are using glibc you really need to see what clone() flags are being passed as fork() is just mapping to clone() with defaults now.

Now some of the other libc variants used by space optimized containers like alpine will still use the legacy fork()

But I constantly see developers confused because they were taught that the v7 style fork() is still used in modern POSIX.

It is didactic and not a rule, focusing on clone() helps get past the change in behavior for both threads and processes.

This author seems to have missed this change in behavior and went on a few crazy paths.

What change in behavior? "v7-style" fork is still used in modern POSIX, and most definitely in HPC/industrial/academic software. If you have no use for threads sharing memory, that is.

If any libc is translating fork() calls into pseudo-equivalents of "vfork" then that libc is just not-POSIX.

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.

To expand on this Linux threads, NPTL and fork() all call clone() under modern Linux and glibc.

The flags on that call and mostly what is inherited or dropped is the main difference.

Add in pid remapping with namespaces in containers and it is common for people to go on wild goose chases if they assume that the legacy fork() model is in play.

Maybe he means "copy on write" for copies of a std::vector, instead of real copy.