Linux系统下，进程可以调用fork函数来创建新的进程。调用进程为父进程，被创建的进程为子进程。

fork函数的接口定义如下：

1. #include <unistd.h>
2. pid_t fork(void);

1. /proc/sys/kernel/sched_child_runs_first

该值默认是0，表示父进程优先获得调度。如果将该值改成1，那么子进程会优先获得调度。

fork之后父子进程的内存关系

fork之后的子进程完全拷贝了父进程的地址空间，包括栈、堆、代码段等。通过下面的示例代码，我们一起来查看父子进程的内存关系：

1. #include <stdio.h>
2. #include <stdlib.h>
3. #include <unistd.h>
4. #include <string.h>
5. #include <errno.h>
6. #include <sys/types.h>
7. #include <wait.h>
8. int g_int = 1;//数据段的全局变量
9. int main()
10. {
11. int local_int = 1;//栈上的局部变量
12. int *malloc_int = malloc(sizeof(int));//通过malloc动态分配在堆上的变量
13. *malloc_int = 1;
14. pid_t pid = fork();
15. if(pid == 0) /*子进程*/
16. {
17. local_int = 0;
18. g_int = 0;
19. *malloc_int = 0;
20. fprintf(stderr,"[CHILD ] child change local global malloc value to 0\n");
21. free(malloc_int);
22. sleep(10);
23. fprintf(stderr,"[CHILD ] child exit\n");
24. exit(0);
25. }
26. else if(pid < 0)
27. {
28. printf("fork failed (%s)",strerror(errno));
29. return 1;
30. }
31. fprintf(stderr,"[PARENT] wait child exit\n");
32. waitpid(pid,NULL,0);
33. fprintf(stderr,"[PARENT] child have exit\n");
34. printf("[PARENT] g_int = %d\n",g_int);
35. printf("[PARENT] local_int = %d\n",local_int);
36. printf("[PARENT] malloc_int = %d\n",local_int);
37. free(malloc_int);
38. return 0;
39. }

1. [PARENT] wait child exit
2. [CHILD ] child change local global malloc value to 0
3. [CHILD ] child exit
4. [PARENT] child have exit
5. [PARENT] g_int = 1
6. [PARENT] local_int = 1
7. [PARENT] malloc_int = 1

 

前文提到过，子进程和父进程执行一模一样的代码的情形比较少见。Linux提供了execve系统调用，构建在该系统调用之上，glibc提供了exec系列函数。这个系列函数会丢弃现存的程序代码段，并构建新的数据段、栈及堆。调用fork之后，子进程几乎总是通过调用exec系列函数，来执行新的程序。

在这种背景下，fork时子进程完全拷贝父进程的数据段、栈和堆的做法是不明智的，因为接下来的exec系列函数会毫不留情地抛弃刚刚辛苦拷贝的内存。为了解决这个问题，Linux引入了写时拷贝（copy-on-write）的技术。

写时拷贝是指子进程的页表项指向与父进程相同的物理内存页，这样只拷贝父进程的页表项就可以了，当然要把这些页面标记成只读（如图4-4所示）。如果父子进程都不修改内存的内容，大家便相安无事，共用一份物理内存页。但是一旦父子进程中有任何一方尝试修改，就会引发缺页异常（page fault）。此时，内核会尝试为该页面创建一个新的物理页面，并将内容真正地复制到新的物理页面中，让父子进程真正地各自拥有自己的物理内存页，然后将页表中相应的表项标记为可写。

从上面的描述可以看出，对于没有修改的页面，内核并没有真正地复制物理内存页，仅仅是复制了父进程的页表。这种机制的引入提升了fork的性能，从而使内核可以快速地创建一个新的进程。

查看下copy_one_pte函数中有如下代码：

1. /*如果是写时拷贝, 那么无论是初始页表, 还是拷贝的页表, 都设置了写保护
2. *后面无论父子进程, 修改页表对应位置的内存时, 都会触发page fault
3. */
4. if (is_cow_mapping(vm_flags)) {
5. ptep_set_wrprotect(src_mm, addr, src_pte);//设置为写保护
6. pte = pte_wrprotect(pte);
7. }

文件描述符还有一个文件描述符标志（file descriptor flag）。目前只定义了一个标志位：FD_CLOSEXEC，这是close_on_exec标志位。细心阅读open函数手册也会发现，open函数也有一个类似的标志位，即O_CLOSEXEC，该标志位也是用于设置文件描述符标志的。

那么这个标志位到底有什么作用呢？如果文件描述符中将这个标志位置位，那么调用exec时会自动关闭对应的文件。

可是为什么需要这个标志位呢？主要是出于安全的考虑。

对于fork之后子进程执行exec这种场景，如果子进程可以操作父进程打开的文件，就会带来严重的安全隐患。一般来讲，调用exec的子进程时，因为它.会另起炉灶，因此父进程打开的文件描述符也应该一并关闭，但事实上内核并没有主动这样做。试想如下场景，Webserver首先以root权限启动，打开只有拥有root权限才能打开的端口和日志等文件，再降到普通用户，fork出一些worker进程，在进程中进行解析脚本、写日志、输出结果等操作。由于子进程完全可以操作父进程打开的文件，因此子进程中的脚本只要继续操作这些文件描述符，就能越权操作root用户才能操作的文件。

注意　图4-7中，多线程程序执行了fork，仅仅是为了示意，实际中并不鼓励这种做法。正相反，这种做法是十分危险的。多线程程序不应该调用fork来创建子进程，第8章会分析具体原因。

前面提到，执行fork时，子进程会获取父进程所有文件描述符的副本，但是测试结果表明，父子进程共享了文件的很多属性。这到底是怎么回事？让我们深入内核一探究竟。

 在内核的进程描述符task_struct结构体中，与打开文件相关的变量如下所示：

1. struct task_struct {
2. ...struct files_struct *files;...
3. }

调用fork时，内核会在copy_files函数中处理拷贝父进程打开的文件的相关事宜：

1. static int copy_files(unsigned long clone_flags,
2. struct task_struct *tsk)
3. {
4. struct files_struct *oldf, *newf;
5. int error = 0;
6. oldf = current->files;//获取父进程的文件结构体
7. if (!oldf)
8. goto out;
9. /*创建线程和vfork, 都不用复制父进程的文件描述符, 增加引用计数即可*/
10. if (clone_flags & CLONE_FILES) {
11. atomic_inc(&oldf->count);
12. goto out;
13. }
14. /*对于fork而言, 需要复制父进程的文件描述符*/
15. newf = dup_fd(oldf, &error); //复制一份文件描述符
16. if (!newf)
17. goto out;
18. tsk->files = newf;
19. error = 0;
20. out:
21. return error;
22. }

CLONE_FILES标志位用来控制是否共享父进程的文件描述符。如果该标志位置位，则表示不必费劲复制一份父进程的文件描述符了，增加引用计数，直接共用一份就可以了。对于vfork函数和创建线程的pthread_create函数来说都是如此。但是fork函数却不同，调用fork函数时，该标志位为0，表示需要为子进程拷贝一份父进程的文件描述符。文件描述符的拷贝是通过内核的dup_fd函数来完成的。

1. struct files_struct *dup_fd(struct files_struct *oldf,
2. int *errorp)
3. {
4. struct files_struct *newf;
5. struct file **old_fds, **new_fds;
6. int open_files, size, i;
7. struct fdtable *old_fdt, *new_fdt;
8. *errorp = -ENOMEM;
9. newf = kmem_cache_alloc(files_cachep, GFP_KERNEL);
10. if (!newf)
11. goto out;

dup_fd函数首先会给子进程分配一个file_struct结构体，然后做一些赋值操作。这个结构体是进程描述符中与打开文件相关的数据结构，每一个打开的文件都会记录在该结构体中。其定义代码如下：

1. struct files_struct {
2. atomic_t count;
3. struct fdtable __rcu *fdt;
4. struct fdtable fdtab;
5. spinlock_t file_lock ____cacheline_aligned_in_smp;
6. int next_fd;
7. struct embedded_fd_set close_on_exec_init;
8. struct embedded_fd_set open_fds_init;
9. struct file __rcu * fd_array[NR_OPEN_DEFAULT];
10. };
11. struct fdtable //文件描述符表
12. {
13. unsigned int max_fds;
14. struct file __rcu **fd; /* current fd array */
15. fd_set *close_on_exec;
16. fd_set *open_fds;
17. struct rcu_head rcu;
18. struct fdtable *next;
19. };
20. struct embedded_fd_set {
21. unsigned long fds_bits[1];
22. };

初看之下struct fdtable的内容与struct files_struct的内容有颇多重复之处，包括close_on_exec文件描述符位图、打开文件描述符位图及file指针数组等，但事实上并非如此。struct files_struct中的成员是相应数据结构的实例，而struct fdtable中的成员是相应的指针。

Linux系统假设大多数的进程打开的文件不会太多。于是Linux选择了一个long类型的位数（32位系统下为32位，64位系统下为64位）作为经验值。

以64位系统为例，file_struct结构体自带了可以容纳64个struct

file类型指针的数组fd_array，也自带了两个大小为64的位图，其中open_fds_init位图用于记录文件的打开情况，close_on_exec_init位图用于记录文件描述符的FD_CLOSEXCE标志位是否置位。只要进程打开的文件个数小于64，file_struct结构体自带的指针数组和两个位图就足以满足需要。因此在分配了file_struct结构体后，内核会初始化file_struct自带的fdtable，代码如下所示：

1. atomic_set(&newf->count, 1);
2. spin_lock_init(&newf->file_lock);
3. newf->next_fd = 0;
4. new_fdt = &newf->fdtab;
5. new_fdt->max_fds = NR_OPEN_DEFAULT;
6. new_fdt->close_on_exec = (fd_set *)&newf->close_on_exec_init;
7. new_fdt->open_fds = (fd_set *)&newf->open_fds_init;
8. new_fdt->fd = &newf->fd_array[0];
9. new_fdt->next = NULL;

初始化之后，子进程的file_struct的情况如图4-8所示。注意，此时file_struct结构体中的fdt指针并未指向file_struct自带的struct fdtable类型的fdtab变量。原因很简单，因为此时内核还没有检查父进程打开文件的个数，因此并不确定自带的结构体能否满足需要。

 

1. spin_lock(&oldf->file_lock);
2. old_fdt = files_fdtable(oldf);
3. open_files = count_open_files(old_fdt);
4. /*如果父进程打开文件的个数超过NR_OPEN_DEFAULT*/
5. while (unlikely(open_files > new_fdt->max_fds)) {
6. spin_unlock(&oldf->file_lock); /* 如果不是自带的fdtable而是曾经分配的fdtable, 则需要先释放*/
7. if (new_fdt != &newf->fdtab)
8. __free_fdtable(new_fdt);
9. /*创建新的fdtable*/
10. new_fdt = alloc_fdtable(open_files - 1);
11. if (!new_fdt) {
12. *errorp = -ENOMEM;
13. goto out_release;
14. }
15. /*如果超出了系统限制, 则返回EMFILE*/
16. if (unlikely(new_fdt->max_fds < open_files)) {
17. __free_fdtable(new_fdt);
18. *errorp = -EMFILE;
19. goto out_release;
20. }
21. spin_lock(&oldf->file_lock);
22. old_fdt = files_fdtable(oldf);
23. open_files = count_open_files(old_fdt);
24. }

alloc_fdtable所做的事情，不过是分配fdtable结构体本身，以及分配一个指针数组和两个位图。分配之前会根据父进程打开文件的数目，计算出一个合理的值nr，以确保分配的数组和位图能够满足需要。

1. old_fds = old_fdt->fd; /*父进程的struct file 指针数组*/
2. new_fds = new_fdt->fd; /*子进程的struct file 指针数组*/
3. /* 拷贝打开文件位图 */
4. memcpy(new_fdt->open_fds->fds_bits,old_fdt->open_fds->fds_bits, open_files/8);
5. /* 拷贝 close_on_exec位图 */
6. memcpy(new_fdt->close_on_exec->fds_bits,old_fdt->close_on_exec->fds_bits, open_files/8);
7. for (i = open_files; i != 0; i--) {
8. struct file *f = *old_fds++;
9. if (f) {
10. get_file(f); /* f对应的文件的引用计数加1 */
11. } else {
12. FD_CLR(open_files - i, new_fdt->open_fds);
13. }
14. /* 子进程的struct file类型指针, *指向和父进程相同的struct file 结构体*/
15. rcu_assign_pointer(*new_fds++, f);
16. }
17. spin_unlock(&oldf->file_lock);/* compute the remainder to be cleared */
18. size = (new_fdt->max_fds - open_files) * sizeof(struct file *);
19. /*将尚未分配到的struct file结构的指针清零*/
20. memset(new_fds, 0, size);/*将尚未分配到的位图区域清零*/
21. if (new_fdt->max_fds > open_files) {
22. int left = (new_fdt->max_fds-open_files)/8;
23. int start = open_files / (8 * sizeof(unsigned long));
24. memset(&new_fdt->open_fds->fds_bits[start], 0, left);
25. memset(&new_fdt->close_on_exec->fds_bits[start], 0, left);
26. }
27.     rcu_assign_pointer(newf->fdt, new_fdt);
28.     return newf;
29. out_release:
30.     kmem_cache_free(files_cachep, newf);
31. out:
32.     return NULL;
33. }

通过对上述流程的梳理，不难看出，父子进程之间拷贝的是struct file的指针，而不是struct file的实例，父子进程的struct file类型指针，都指向同一个struct file实例。fork之后，父子进程的文件描述符关系如图4-10所示。

进程的创建之vfork（）

在早期的实现中，fork没有实现写时拷贝机制，而是直接对父进程的数据段、堆和栈进行完全拷贝，效率十分低下。很多程序在fork一个子进程后，会紧接着执行exec家族函数，这更是一种浪费。所以BSD引入了vfork。既然fork之后会执行exec函数，拷贝父进程的内存数据就变成了一种无意义的行为，所以引入的vfork压根就不会拷贝父进程的内存数据，而是直接共享。再后来Linux引入了写时拷贝的机制，其效率提高了很多，这样一来，vfork其实就可以退出历史舞台了。除了一些需要将性能优化到极致的场景，大部分情况下不需要再使用vfork函数了。

1. #include<stdio.h>
2. #include <stdlib.h>
3. #include <unistd.h>
4. int glob = 88 ;
5. int main(void) {
6. int var;
7. var = 88;
8. pid_t pid;
9. if ((pid = vfork()) < 0) {
10. printf("vfork error");
11. exit(-1);
12. } else if (pid == 0) { /* 子进程 */
13. var++;
14. glob++;
15. return 0;
16. }printf("pid=%d, glob=%d, var=%d\n",getpid(), glob, var);
17. return 0;
18. }

调用子进程，如果使用return返回，就意味着main函数返回了，因为栈是父子进程共享的，所以程序的函数栈发生了变化。main函数return之后，通常会调用exit系的函数，父进程收到子进程的exit之后，就会开始从vfork返回，但是这时整个main函数的栈都已经不复存在了，所以父进程压根无法执行。于是会返回一个诡异的栈地址，对于在某些内核版本中，进程会直接报栈错误然后退出，但是在某些内核版本中，有可能就会再次进出main，于是进入一个无限循环，直到vfork返回错误。笔者的Ubuntu版本就是后者。返回。一般来说，vfork创建的子进程会执行exec，执行完exec后应该调用_exit,注意是_exit而不是exit。因为exit会导致父进程stdio缓冲区的冲刷和关闭。我们会在后面讲述exit和_exit的区别。