I think the overall sentiment is right on, but I'm not sure I get the last question. posix is a superset, yes, but it doesn't provide replacements for the C library. Perhaps better phrased as "Why limit yourself to only standard C?"?
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. The glibc wrapper invokes any fork handlers that have been established using pthread_atfork(3).
At least on my ubuntu box.
andrew-think ⚑ ~ strace -f sh -c 'sh &' 2>&1 | egrep -A1 'clone|fork'
clone(Process 2646 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ff002bac9d0) = 2646POSIX itself doesn't even use the words system call, only function, to describe them.
$ grep fork /usr/include/asm/unistd_64.h
#define __NR_fork 57
__SYSCALL(__NR_fork, stub_fork)
#define __NR_vfork 58
__SYSCALL(__NR_vfork, stub_vfork)
$ strace -f ruby -e 'syscall 57' 2>&1 | egrep 'fork|clone'
fork(Process 4138 attached (waiting for parent)
$ strace -f ruby -e 'fork' 2>&1 | egrep 'fork|clone'
execve("/home/andrew/.rvm/rubies/ree-1.8.7-2010.02/bin/ruby", ["ruby", "-e", "fork"], [/* 47 vars */]) = 0
clone(Process 4145 attachedWhat makes Linux as an operating system conform to POSIX is the API, implemented in C. In this API, the function fork() has to do what the POSIX specification states. As stated, this fork() does not even use the system call fork in the resent versions of glibc.
As POSIX is a superset of the C standard library, it does provide a replacement. The C standard library exists to provide the very basic functionality in it, in environments and operating systems that are not POSIX compliant.
C standard library is part of the C implementation. The POSIX API, implemented in what ever language, is part of the operating system.
That looks to be some questionable phrasing from the article.
Yes, fork() is a system call on many platforms, but not on all.
And fork() is not ubiquitous. If anything, it's one of the common and can be one of the more intractable sources of porting problems within C code.
fork() does rather more than many C programmers might realize. About 5 or 10% of the calls I've encountered in the many C applications I've ported will use fork() for most or all of what it can do. The remaining calls throw that context away, and can often be equally or better served with vfork()/exec() or some other C call.
Those applications that use fork() for what it can do can be and usually are more difficult to port to the various platforms that lack copy-on-read virtual memory.
Every single major operating system except one has fork. Colour me not very concerned.