4 ms·

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

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.

nyrikki 5y ago
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.
AshamedCaptain 5y ago
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.
- nyrikki 5y ago
  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 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)."
  - nyrikki 5y ago
    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/sched.h 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
  - AshamedCaptain 5y ago
    So there is no change in visible behavior, it is just an implementation detail.
    - nyrikki 5y ago
      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.

nyrikki 5y ago

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.

AshamedCaptain 5y ago

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.

nyrikki 5y ago
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 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)."
- nyrikki 5y ago
  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/sched.h 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
- AshamedCaptain 5y ago
  So there is no change in visible behavior, it is just an implementation detail.
  - nyrikki 5y ago
    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.