文章目录
- 回顾进程
- 查看进程的方式
- fork
回顾进程
前面对进程进行了一些初步的认知，比如进程=可执行程序+内核数据结构PCB，再比如可以通过ps命令搭配管道寻找进程，通过/proc系统文件夹查看进程的信息，这些都是前面对进程建立起来的一些初步的认知
查看进程的方式
下面引入在函数中使用进程的函数，getpid()和gitppid
#include <stdio.h>
#include <unistd.h>
int main()
{
while(1)
{
printf("process id:%d,parent process id:%d\n",getpid(),getppid());
sleep(1);
}
return 0;
}
这两个函数的功能，就是得到进程的id和父进程的id
实现Makefile
cc=gcc
src=process.c
target=process
$(target):$(src)
gcc -o $@ $^
.PHONY:clean
clean:
rm -f $(target)
在启动程序前，为了便于观察进程的变化情况，我们可以借助ps命令来观察，但是ps命令不能做到实时观察目前我们的进程变换情况，因此使用一个脚本来自动的观察进程的情况
# 打印ps指令的题头和利用ps指令寻找关于process的进程信息，打印一次暂停1s，再使用####进行分割每次打印的信息
while :; do ps ajx |head -1 && ps ajx | grep process; sleep 1;echo "###################################"; done
执行程序和脚本
下面对这个程序进行多次执行
# 第一次可执行程序运行的结果
process id:11389,parent process id:7945
# 进程监视的结果
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
7945 11389 11389 7945 pts/0 11389 S+ 1003 0:00 ./process
# 第二次可执行程序运行的结果
process id:14823,parent process id:7945
# 进程监视的结果
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
7945 14823 14823 7945 pts/0 14823 S+ 1003 0:00 ./process
# 第三次可执行程序运行的结果
process id:15279,parent process id:7945
# 进程监视的结果
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
7945 15279 15279 7945 pts/0 15279 S+ 1003 0:00 ./process
输出结果如上，从中可以看出这个函数是可以打印出进程的信息的，和实际的信息也确实对应，但是有一个现象，父进程一直都是7945，为什么不变呢？
理解系统接口调用
从这里其实可以更深层次的理解下图中关于系统调用接口的概念，我们使用的不管是getpid还是getppid，实际上都是要调用系统的接口，操作系统再帮我们进行一个搜索后把结果返还给用户，逻辑上是很简单的一个过程
那么现在有了函数的调用，用户也可以直接去得到进程的id信息，下面进行第二种查看进程的方式，使用/proc文件来查看
proc文件夹，是一个动态的目录结构，里面存放的是所有存在的进程，而目录的名称就是以这个进程的id来命名的
下面展示了/proc文件夹下的各种进程内容，每一个文件夹其实都对应了一个进程，每一个进程文件夹下的内容其实就是每个进程的PCB，那么下面就要进入进程内，看这些进程内到底包含什么东西
[test@VM-16-11-centos process]$ ls /proc -l
total 0
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1
dr-xr-xr-x 9 root root 0 Sep 11 17:49 10
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1005
dr-xr-xr-x 9 test test 0 Sep 23 19:42 10082
dr-xr-xr-x 9 root root 0 Sep 11 17:49 106
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1070
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1072
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1075
dr-xr-xr-x 9 root root 0 Sep 23 19:45 10935
dr-xr-xr-x 9 root root 0 Sep 11 17:49 11
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1180
dr-xr-xr-x 9 root root 0 Sep 11 17:49 1188
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1195
dr-xr-xr-x 9 root root 0 Sep 11 17:49 12
dr-xr-xr-x 9 root root 0 Sep 11 17:49 1205
dr-xr-xr-x 9 root root 0 Sep 11 17:49 1206
dr-xr-xr-x 9 root root 0 Sep 11 17:49 13
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1318
dr-xr-xr-x 9 postfix postfix 0 Jul 15 22:07 1328
dr-xr-xr-x 9 root root 0 Jul 15 22:07 1370
dr-xr-xr-x 9 root root 0 Sep 11 17:49 14
dr-xr-xr-x 9 postfix postfix 0 Sep 23 19:55 14576
dr-xr-xr-x 9 root root 0 Sep 11 17:53 14808
dr-xr-xr-x 9 root root 0 Sep 11 17:53 14911
dr-xr-xr-x 9 root root 0 Aug 30 10:08 15264
dr-xr-xr-x 9 root root 0 Sep 11 17:49 1565
dr-xr-xr-x 9 root root 0 Sep 11 17:49 16
dr-xr-xr-x 9 root root 0 Sep 23 20:03 17216
dr-xr-xr-x 9 root root 0 Sep 23 20:05 17758
dr-xr-xr-x 9 root root 0 Sep 11 17:49 18
dr-xr-xr-x 9 ntp ntp 0 Jul 15 22:07 1800
dr-xr-xr-x 9 test test 0 Sep 23 20:09 18814
dr-xr-xr-x 9 root root 0 Sep 11 17:49 19
dr-xr-xr-x 9 root root 0 Sep 23 20:10 19001
dr-xr-xr-x 9 root root 0 Sep 23 20:12 19441
dr-xr-xr-x 9 root root 0 Sep 11 17:49 2
dr-xr-xr-x 9 root root 0 Sep 11 17:49 20
dr-xr-xr-x 9 root root 0 Aug 31 20:02 20043
dr-xr-xr-x 9 root root 0 Aug 31 20:02 20051
dr-xr-xr-x 9 root root 0 Aug 31 20:02 20052
dr-xr-xr-x 9 root root 0 Sep 23 20:15 20184
dr-xr-xr-x 9 test test 0 Sep 23 20:15 20221
dr-xr-xr-x 9 root root 0 Sep 11 17:49 203
dr-xr-xr-x 9 test test 0 Sep 12 12:11 20530
dr-xr-xr-x 9 test test 0 Sep 12 12:11 20543
dr-xr-xr-x 9 root root 0 Sep 11 17:49 21
dr-xr-xr-x 9 root root 0 Sep 11 17:49 22
dr-xr-xr-x 9 root root 0 Sep 11 17:49 23
dr-xr-xr-x 9 root root 0 Sep 11 17:49 24
dr-xr-xr-x 9 root root 0 Sep 11 17:49 25
dr-xr-xr-x 9 root root 0 Sep 11 17:49 253
dr-xr-xr-x 9 root root 0 Sep 11 17:49 26
dr-xr-xr-x 9 root root 0 Sep 11 17:49 262
dr-xr-xr-x 9 root root 0 Sep 11 17:49 267
dr-xr-xr-x 9 root root 0 Sep 11 17:49 268
dr-xr-xr-x 9 root root 0 Sep 11 17:49 269
dr-xr-xr-x 9 root root 0 Sep 11 17:49 27
dr-xr-xr-x 9 root root 0 Sep 11 17:49 272
dr-xr-xr-x 9 root root 0 Sep 11 17:49 277
dr-xr-xr-x 9 root root 0 Sep 11 17:49 28
dr-xr-xr-x 9 root root 0 Sep 11 17:49 29
dr-xr-xr-x 9 root root 0 Sep 11 17:49 292
dr-xr-xr-x 9 root root 0 Sep 11 17:49 293
dr-xr-xr-x 9 root root 0 Sep 22 18:22 29767
dr-xr-xr-x 9 root root 0 Sep 11 17:49 300
dr-xr-xr-x 9 root root 0 Sep 23 19:15 3061
dr-xr-xr-x 9 root root 0 Sep 21 20:36 3243
dr-xr-xr-x 9 root root 0 Sep 11 17:49 35
dr-xr-xr-x 9 root root 0 Sep 11 17:49 36
dr-xr-xr-x 9 root root 0 Sep 11 17:49 37
dr-xr-xr-x 9 root root 0 Sep 11 17:49 38
dr-xr-xr-x 9 root root 0 Jul 15 22:07 381
dr-xr-xr-x 9 root root 0 Sep 11 17:49 4
dr-xr-xr-x 9 root root 0 Jul 15 22:07 404
dr-xr-xr-x 9 root root 0 Jul 15 22:07 409
dr-xr-xr-x 9 root root 0 Sep 11 17:49 46
dr-xr-xr-x 9 root root 0 Sep 11 17:49 48
dr-xr-xr-x 9 root root 0 Sep 11 17:49 49
dr-xr-xr-x 9 root root 0 Sep 11 17:49 501
dr-xr-xr-x 9 root root 0 Sep 11 17:49 51
dr-xr-xr-x 9 root root 0 Jul 15 22:07 515
dr-xr-xr-x 9 root root 0 Sep 11 17:49 52
dr-xr-xr-x 9 root root 0 Jul 15 22:16 5449
dr-xr-xr-x 9 libstoragemgmt libstoragemgmt 0 Jul 15 22:07 556
dr-xr-xr-x 9 dbus dbus 0 Jul 15 22:07 561
dr-xr-xr-x 9 root root 0 Jul 15 22:07 566
dr-xr-xr-x 9 root root 0 Jul 15 22:07 567
dr-xr-xr-x 9 polkitd polkitd 0 Jul 15 22:07 568
dr-xr-xr-x 9 root root 0 Sep 11 17:49 6
dr-xr-xr-x 9 root root 0 Sep 11 17:49 612
dr-xr-xr-x 9 root root 0 Sep 11 17:49 613
dr-xr-xr-x 9 root root 0 Sep 11 17:49 614
dr-xr-xr-x 9 root root 0 Sep 11 17:49 615
dr-xr-xr-x 9 root root 0 Sep 11 17:49 616
dr-xr-xr-x 9 root root 0 Sep 11 17:49 621
dr-xr-xr-x 9 root root 0 Sep 11 17:49 65
dr-xr-xr-x 9 root root 0 Sep 11 17:49 7
dr-xr-xr-x 9 root root 0 Sep 23 19:34 7937
dr-xr-xr-x 9 test test 0 Sep 23 19:34 7944
dr-xr-xr-x 9 test test 0 Sep 23 19:34 7945
dr-xr-xr-x 9 root root 0 Sep 11 17:49 8
dr-xr-xr-x 9 root root 0 Sep 11 17:49 9
dr-xr-xr-x 2 root root 0 Sep 23 20:15 acpi
-r--r--r-- 1 root root 0 Sep 23 20:15 buddyinfo
dr-xr-xr-x 4 root root 0 Sep 23 20:15 bus
-r--r--r-- 1 root root 0 Sep 23 20:15 cgroups
-r--r--r-- 1 root root 0 Sep 23 20:15 cmdline
-r--r--r-- 1 root root 0 Sep 23 20:15 consoles
-r--r--r-- 1 root root 0 Sep 23 20:15 cpuinfo
-r--r--r-- 1 root root 0 Sep 23 20:15 crypto
-r--r--r-- 1 root root 0 Sep 23 20:15 devices
-r--r--r-- 1 root root 0 Sep 23 20:15 diskstats
-r--r--r-- 1 root root 0 Sep 23 20:15 dma
dr-xr-xr-x 3 root root 0 Sep 23 20:15 driver
-r--r--r-- 1 root root 0 Sep 23 20:15 execdomains
-r--r--r-- 1 root root 0 Sep 23 20:15 fb
-r--r--r-- 1 root root 0 Sep 23 20:15 filesystems
dr-xr-xr-x 5 root root 0 Sep 23 20:15 fs
-r--r--r-- 1 root root 0 Sep 23 20:15 interrupts
-r--r--r-- 1 root root 0 Sep 23 20:15 iomem
-r--r--r-- 1 root root 0 Sep 23 20:15 ioports
dr-xr-xr-x 25 root root 0 Sep 23 20:15 irq
-r--r--r-- 1 root root 0 Sep 23 20:15 kallsyms
-r-------- 1 root root 140737486266368 Sep 23 20:15 kcore
-r--r--r-- 1 root root 0 Sep 23 20:15 keys
-r--r--r-- 1 root root 0 Sep 23 20:15 key-users
-r-------- 1 root root 0 Sep 23 20:15 kmsg
-r-------- 1 root root 0 Sep 23 20:15 kpagecount
-r-------- 1 root root 0 Sep 23 20:15 kpageflags
-r--r--r-- 1 root root 0 Sep 23 20:15 loadavg
-r--r--r-- 1 root root 0 Sep 23 20:15 locks
-r--r--r-- 1 root root 0 Sep 23 20:15 mdstat
-r--r--r-- 1 root root 0 Sep 23 20:15 meminfo
-r--r--r-- 1 root root 0 Sep 23 20:15 misc
-r--r--r-- 1 root root 0 Sep 23 20:15 modules
lrwxrwxrwx 1 root root 11 Sep 23 20:15 mounts -> self/mounts
-rw-r--r-- 1 root root 0 Sep 23 20:15 mtrr
lrwxrwxrwx 1 root root 8 Sep 23 20:15 net -> self/net
-r-------- 1 root root 0 Sep 23 20:15 pagetypeinfo
-r--r--r-- 1 root root 0 Sep 23 20:15 partitions
-r--r--r-- 1 root root 0 Sep 23 20:15 sched_debug
-r--r--r-- 1 root root 0 Sep 23 20:15 schedstat
dr-xr-xr-x 3 root root 0 Sep 23 20:15 scsi
lrwxrwxrwx 1 root root 0 Jul 15 22:07 self -> 20221
-r-------- 1 root root 0 Sep 23 20:15 slabinfo
-r--r--r-- 1 root root 0 Sep 23 20:15 softirqs
-r--r--r-- 1 root root 0 Sep 23 20:15 stat
-r--r--r-- 1 root root 0 Jul 15 22:07 swaps
dr-xr-xr-x 1 root root 0 Jul 15 22:07 sys
--w------- 1 root root 0 Sep 23 20:15 sysrq-trigger
dr-xr-xr-x 2 root root 0 Sep 23 20:15 sysvipc
-r--r--r-- 1 root root 0 Sep 23 20:15 timer_list
-rw-r--r-- 1 root root 0 Sep 23 20:15 timer_stats
dr-xr-xr-x 4 root root 0 Sep 23 20:15 tty
-r--r--r-- 1 root root 0 Sep 23 20:15 uptime
-r--r--r-- 1 root root 0 Sep 23 20:15 version
-r-------- 1 root root 0 Sep 23 20:15 vmallocinfo
-r--r--r-- 1 root root 0 Sep 23 20:15 vmstat
dr-xr-xr-x 2 root root 0 Sep 23 20:15 xpmem
-r--r--r-- 1 root root 0 Sep 23 20:15 zoneinfo
对于产生的结果过多，不太好观察，因此这里将前面的程序启动，看进程中到底有什么文件和信息可以进行获取
# 启动程序
process id:18814,parent process id:7945
# 查看进程内容
[test@VM-16-11-centos process]$ ls /proc/18814 -l
total 0
dr-xr-xr-x 2 test test 0 Sep 23 20:10 attr
-rw-r--r-- 1 test test 0 Sep 23 20:10 autogroup
-r-------- 1 test test 0 Sep 23 20:10 auxv
-r--r--r-- 1 test test 0 Sep 23 20:10 cgroup
--w------- 1 test test 0 Sep 23 20:10 clear_refs
-r--r--r-- 1 test test 0 Sep 23 20:09 cmdline
-rw-r--r-- 1 test test 0 Sep 23 20:10 comm
-rw-r--r-- 1 test test 0 Sep 23 20:10 coredump_filter
-r--r--r-- 1 test test 0 Sep 23 20:10 cpuset
lrwxrwxrwx 1 test test 0 Sep 23 20:09 cwd -> /home/test/process
-r-------- 1 test test 0 Sep 23 20:09 environ
lrwxrwxrwx 1 test test 0 Sep 23 20:09 exe -> /home/test/process/process
dr-x------ 2 test test 0 Sep 23 20:09 fd
dr-x------ 2 test test 0 Sep 23 20:10 fdinfo
-rw-r--r-- 1 test test 0 Sep 23 20:10 gid_map
-r-------- 1 test test 0 Sep 23 20:10 io
-r--r--r-- 1 test test 0 Sep 23 20:10 limits
-rw-r--r-- 1 test test 0 Sep 23 20:10 loginuid
dr-x------ 2 test test 0 Sep 23 20:10 map_files
-r--r--r-- 1 test test 0 Sep 23 20:10 maps
-rw------- 1 test test 0 Sep 23 20:10 mem
-r--r--r-- 1 test test 0 Sep 23 20:10 mountinfo
-r--r--r-- 1 test test 0 Sep 23 20:10 mounts
-r-------- 1 test test 0 Sep 23 20:10 mountstats
dr-xr-xr-x 5 test test 0 Sep 23 20:10 net
dr-x--x--x 2 test test 0 Sep 23 20:10 ns
-r--r--r-- 1 test test 0 Sep 23 20:10 numa_maps
-rw-r--r-- 1 test test 0 Sep 23 20:10 oom_adj
-r--r--r-- 1 test test 0 Sep 23 20:10 oom_score
-rw-r--r-- 1 test test 0 Sep 23 20:10 oom_score_adj
-r--r--r-- 1 test test 0 Sep 23 20:10 pagemap
-r-------- 1 test test 0 Sep 23 20:10 patch_state
-r--r--r-- 1 test test 0 Sep 23 20:10 personality
-rw-r--r-- 1 test test 0 Sep 23 20:10 projid_map
lrwxrwxrwx 1 test test 0 Sep 23 20:09 root -> /
-rw-r--r-- 1 test test 0 Sep 23 20:10 sched
-r--r--r-- 1 test test 0 Sep 23 20:10 schedstat
-r--r--r-- 1 test test 0 Sep 23 20:10 sessionid
-rw-r--r-- 1 test test 0 Sep 23 20:10 setgroups
-r--r--r-- 1 test test 0 Sep 23 20:10 smaps
-r--r--r-- 1 test test 0 Sep 23 20:10 stack
-r--r--r-- 1 test test 0 Sep 23 20:09 stat
-r--r--r-- 1 test test 0 Sep 23 20:10 statm
-r--r--r-- 1 test test 0 Sep 23 20:09 status
-r--r--r-- 1 test test 0 Sep 23 20:10 syscall
dr-xr-xr-x 3 test test 0 Sep 23 20:10 task
-r--r--r-- 1 test test 0 Sep 23 20:10 timers
-rw-r--r-- 1 test test 0 Sep 23 20:10 uid_map
-r--r--r-- 1 test test 0 Sep 23 20:10 wchan
上面演示了查看进程中文件的信息的方法，针对上面的信息，选两个来进行总结
lrwxrwxrwx 1 test test 0 Sep 23 20:09 cwd -> /home/test/process
lrwxrwxrwx 1 test test 0 Sep 23 20:09 exe -> /home/test/process/process
这里挑选出了两个内容，一个是cwd，一个是exe，选这两个也是有原因的，这两个可以挖掘出可值得学习的点
cwd
在解决问题前要先知道什么是cwd，它的全程叫做current working directory，也就是所谓的当前工作目录，一般叫它叫当前目录，对于当前目录这个概念并不陌生，但什么是当前目录？
前面对于进程的定义中讲到，操作系统会创建出一个PCB来管理进入内存中的可执行程序，那么可执行程序是如何被管理的？该如何理解管理的概念？一个进程，要能找到自己的可执行程序，这样才能被称为管理起来，因此，这就意味着每一个进程都要有自己的工作目录，而默认情况下，进程启动的时候所处的路径就是当前路径
既然这是默认，那么当前路径也是可以更改的，有一个函数叫做chdir()函数，它的功能就是用以更变工作路径的，在Linux下使用man指令查看：
SYNOPSIS
#include <unistd.h>
int chdir(const char *path);
int fchdir(int fd);
因此用实验来证明它的存在
对程序略做修改，让程序可以在工作目录下创建文件，可以使用C语言的文件操作来实现
#include <stdio.h>
#include <unistd.h>
int main()
{
FILE* pf=fopen("test.txt","w");
if(pf==NULL)
{
perror("fopen fail!\n");
return 1;
}
fclose(pf);
return 0;
}
编译运行结果，此时在process路径下就产生了一个test.txt文件，这也说明默认的工作路径就是进程启动的时候所处的环境，此时再看proc文件下的信息
[test@VM-16-11-centos process]$ ls /proc/3466 -l
total 0
lrwxrwxrwx 1 test test 0 Sep 23 21:17 cwd -> /home/test
lrwxrwxrwx 1 test test 0 Sep 23 21:17 exe -> /home/test/process/process
此时确实是被改变了，说明和前面是一样的
[test@VM-16-11-centos process]$ make
gcc -o process process.c
[test@VM-16-11-centos process]$ ./process
[test@VM-16-11-centos process]$ ll
total 20
-rw-rw-r-- 1 test test 106 Sep 23 19:39 Makefile
-rwxrwxr-x 1 test test 8464 Sep 23 20:47 process
-rw-rw-r-- 1 test test 203 Sep 23 20:45 process.c
-rw-rw-r-- 1 test test 0 Sep 23 20:47 test.txt
那么对于程序再略做修改
#include <stdio.h>
#include <unistd.h>
int main()
{
chdir("/home/test");
FILE* pf=fopen("test.txt","w");
if(pf==NULL)
{
perror("fopen fail!\n");
return 1;
}
fclose(pf);
return 0;
}
此时将工作目录改到了家目录的一个文件夹下，此时再看test.txt的位置
[test@VM-16-11-centos ~]$ pwd
/home/test
[test@VM-16-11-centos ~]$ ll
-rw-rw-r-- 1 test test 0 Sep 23 20:50 test.txt
此时程序生成的文件就默认创建到了这个文件夹内，此时打开/proc文件，再看进程的描述
exe
exe表示的就是当前正在执行的可执行程序，如果把可执行程序从磁盘中删除
[test@VM-16-11-centos process]$ ll
total 20
-rw-rw-r-- 1 test test 106 Sep 23 19:39 Makefile
-rwxrwxr-x 1 test test 8520 Sep 23 19:46 process
-rw-rw-r-- 1 test test 187 Sep 23 19:46 process.c
[test@VM-16-11-centos process]$ rm process
[test@VM-16-11-centos process]$ ll
total 8
-rw-rw-r-- 1 test test 106 Sep 23 19:39 Makefile
-rw-rw-r-- 1 test test 187 Sep 23 19:46 process.c
但是程序依旧在运行，这是为什么？
这是因为，磁盘中的文件被删除了，其实和进程关系并不大，进程被运行前就已经被加载到内存中了，因此磁盘上文件的删除对于内存并不会造成决定性的影响，但是如果程序终止想要重新运行，可能就并不可以了，但是在proc文件内，会为用户标出错误提示，说明在磁盘中的可执行程序已经被删掉了
lrwxrwxrwx 1 test test 0 Sep 23 20:09 cwd -> /home/test/process
lrwxrwxrwx 1 test test 0 Sep 23 20:09 exe -> /home/test/process/process (deleted)
那么有几个问题就随之产生了：
- 这个父进程是谁，为什么一直不变？
对于这个问题，可以使用ps命令来查看，而结果是bash，也就是命令行解释器
[test@VM-16-11-centos process]$ ps ajx |head -1 && ps ajx | grep 7945
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
7944 7945 7945 7945 pts/0 16488 Ss 1003 0:00 -bash
- 父进程的概念如何理解？
关于这个问题，后续和fork一起总结
Linux中创建进程的方式通常有两种：
- 命令行中直接启动进程
- 通过代码来创建进程
对于第一种很好理解，执行程序./process其实就是启动进程，那第二种是什么？如何理解这个概念？就引出了本篇的核心，系统调用fork
启动进程，本质就是创建进程，一般都是通过父进程创建的
关于如何创建进程，下面用fork来讲述
fork
首先要对fork有一个初步认知，它可以给当前的进程添加一个子进程，它可以使用代码来创建进程，它是属于系统级别的调用：
- 当用户启动一个进程的时候，如何理解在行为？其实就是在系统重多增加一个进程，操作系统要管理的进程就多了一个
- 创建一个进程，就是要向系统中申请一些内存，保存当前进程的可执行程序并且要创建这个进程的
PCB，也就是task_struct对象，并且将这个对象添加到进程列表中
那么如何来观察现象？
对程序进行改变
#include <stdio.h>
#include <unistd.h>
int main()
{
printf("Before fork:the pid is %d,the ppid is %d\n",getpid(),getppid());
fork();
printf("After fork:the pid is %d,the ppid is %d\n",getpid(),getppid());
return 0;
}
运行程序
# 运行程序
[test@VM-16-11-centos process]$ ./process
# 运行结果
Before fork:the pid is 7810,the ppid is 6523
After fork:the pid is 7810,the ppid is 6523
After fork:the pid is 7811,the ppid is 7810
现象很神奇，程序中只打印了一次After fork...，但却输出了两次，并且第二次输出的结果的ppid就是第一次输出的pid，这是不是证明第二次输出的这个7811就是7810的子进程？
答案是肯定的，并且fork之后这两个进程都会执行它们自己的程序，由此展开关于fork的理解
fork的具体描述
使用man指令查看fork的帮助文档内的信息
NAME
fork - create a child process
SYNOPSIS
#include <unistd.h>
pid_t fork(void);
从上面的表述中，可以获取到一些信息，fork的功能就是创建一个子进程，fork函数有两个返回值，给子进程返回0，给父进程返回子进程的pid
为什么要使用fork？
在C语言中，写的代码的执行逻辑都是从上向下执行（默认情况下），但是事实上在一些情况下这样的需求满足不了用户的需求，例如要边下载一个电影边播放它，那么这个时候就需要创建一个子进程来帮助实现这个功能，这是单进程所解决不了的，因此级有了fork函数，有了这个函数可以让父进程和子进程做不一样的事，执行不一样的代码，通过fork的返回值就能判断谁是子进程谁是父进程，就可以让它们实现不同的代码片段，执行不同的功能
fork做了些什么？
从表面上看，fork函数在执行后，增加了一个进程，这个进程和原来的父进程会一起执行下去，分别在自己的进程下输出内容（以这个代码为例子），但是这都是表象，从深层次的角度来看，fork的实现过程并不简单
既然是子进程，也属于进程，是进程就要创建程序的PCB，那现在有了关于task_struct，里面的信息在哪里？拷贝的内容是什么？答案是以父进程为模板，为子进程创建PCB，而创建的PCB指向的可执行文件并没有创建，因此这里实现的子进程没有它自己的代码和数据，只是和父进程共享代码和数据，用下图来描述上面的这一系列过程如下：
上图清晰的把前文进行了图示化，创建出的子进程也有自己的PCB，内容来自于父进程的PCB，直接拷贝而来，而它的可执行文件是共享的父进程的可执行文件
fork之后，父子进程会执行同样的代码，fork之前的代码父子进程也都有记录
fork之后会执行同样的代码
-
fork之前的代码可以看到吗？可以看到，父子进程都有前面代码的数据 -
子进程为什么不从头开始执行？这是由于
pc/eip执行fork完毕后，eip指向的是fork后续的代码，eip也会被子进程继承，因此直接执行的是fork之后的代码
进程的独立性如何理解？
关于进程的独立性，可以从下面的角度入手，首先，进程独立性可以从每一个进程都有它自己的PCB来看出，进程之间是不会被相互影响的，但是数据父子是会被修改的，那么可以采用写实拷贝的方法来将这个过程执行下去，进程的代码可以共享，但是进程的数据不可以，数据每一个进程只能拥有一份，不然对于一些全局变量来说，一个进程对于全局变量的改变会使得另外一个进程受到严重的影响，因此上面的图其实并不完全正确，应该这样改良
新创建的子进程的PCB中，对于可执行文件的拥有应该分为两部分，代码片段和数据片段，对于代码片段可以进行共享，但是对于数据片段一定是每一个进程拥有一份独立的数据，这样才能保证进程的独立性
fork之后，父子进程谁先运行？
创建完成子进程，只是开始，系统中有其他进程，父进程和子进程，接下来谁先被执行要看谁先被调度，先被调度的就要先运行，那么有具体的规则吗？没有，这是由操作系统自己来决定的，由每个进程PCB中的调度信息，比如说时间片优先级等等，和调度器算法共同决定谁优先被调用
如何理解fork？
从本质上来讲，fork其实就是一个函数，那么它函数中的内容会有哪些？
- 找到父进程的
PCB对象 malloc一个PCB用来放子进程- 用父进程的
PCB来初始化子进程 - 让子进程的
PCB指向父进程的代码和数据 - 子进程和父进程都加入调度队列开始排队
- …
简单来说，就是创建子进程，将子进程放到调度队列中运行
以上为对fork的初步理解，后续会继续用它实现系统级别的代码
