A fork() in the road

Re:A fork() in the road by swiley on Wednesday April 10, 2019 @01:09AM (#19622029)

I thought Linux had clone which glibc called for their implementation of fork.

[ Parent | on HN ]

Re:A fork() in the road by zenexer on Wednesday April 10, 2019 @01:54AM (#19622221)

Yes, the underlying syscall for fork() is clone [1], and the underlying syscall for exec*() is execve [2].

[1]: http://man7.org/linux/man-pages/man2/fork.2.html#NOTES

[2]: http://man7.org/linux/man-pages/man2/execve.2.html

[ Parent | on HN ]

Re:A fork() in the road by eesmith on Wednesday April 10, 2019 @01:53AM (#19622213)

Section 6: REPLACING FORK

> Alternative: clone().

> This syscall underlies all process and thread creation on Linux. Like Plan 9’s rfork() which preceded it, it takes separate flags controlling the child’s kernel state: address space, file descriptor table, namespaces, etc. This avoids one problem of fork: that its behaviour is implicit or undefined for many abstractions. However, for each resource there are two options: either share the resource between parent and child, or else copy it. As a result, clone suffers most of the same problems as fork (§4–5).

[ Parent | on HN ]