一、进程创建
fork函数
在Linux中fork函数是非常重要的函数,它从已存在进程中创建一个新进程,原进程为父进程
fork函数的功能:
- 分配新的内存和内核数据结构给子进程
- 将父进程部分数据结构内容拷贝至子进程
- 添加子进程到系统的进程列表中
- fork返回,开始调度器调度
fork函数的返回值:
- 子进程返回0
- 父进程返回子进程的pid
- 创建进程失败返回
写实拷贝
在进程地址空间中,我们解释了父子进程的数据相同地址不同值的问题,那么现在我们来谈谈OS是具体怎么实现的,下面给大家画个草图
fork的常规用法
- 一个父进程希望复制自己,使父子进程同时执行不同的代码段。例如,父进程等待客户端请求,生成子进程来处理请求
- 一个进程要执行一个不同的程序。例如子进程从fork返回后,调用exec函数
fork调用失败的原因
- 系统中有太多的进程
- 实际用户的进程数超过了限制
二、进程终止
进程退出场景
- 代码运行完毕,结果正确
- 代码运行完毕,结果不正确
- 代码异常终止
为什么要介绍这个?因为系统创建进程本质是让进程去完成一些工作,那么系统当然有必要去了解工作的结果,如果成功了,那么万事大吉,如果代码错误,不管是代码运行完毕结果错误还是出现异常提前终止,操作系统都需要知道原因,那么如何知道进程失败的原因呢?
1.代码运行完毕,结果不正确
相信大家在写C语言的时候,main方法里总是会写return 0;这个语句,现在我们应该明白,其实这就是告诉父进程,该进程工作顺利完成,同时我们也或多或少在控制台的黑窗口中见过某某程序返回值不为0的情况。这些返回值统一叫做退出码,对应一些数字,而每一个数字对应一个字符串
当然这个退出码也是可以自定义的
这个和C语言中学的errno(错误码)这个全局变量很相似(大家可以去查查C的文档),只不过退出码是记录进程跑完后的结果是否正确及错误的原因,错误码记录库函数/系统接口,即函数运行失败的原因
2.代码异常终止
上面两个程序都是异常终止,操作系统检测到进程异常通过信号直接杀掉进程(因为操作系统是进程的管理者)
总结:
1.进程是否异常,看有没有收到信号
2.进程运行结果是否正确和错误的原因,看退出码
(进程异常结束后,退出码就没有意义了)
3.进程常见的退出方法
正常终止(可以通过echo $?查看进程的退出码):
- 从main返回(执行return n等同于执行exit(n),因为调用main的运行时函数会将main的返回值当做 exit的参数)---这里的return仅限于main函数中的,其他函数的return不具有结束进程的功能,这里就不做过多介绍了
- 调用exit(库函数)
- 调用_exit(系统接口)
1.exit---库函数
2._exit---系统调用接口
上面的代码运行结果和exit一样,就是将exit函数换成了_exit函数,结论和上面一样
那么这两个函数有什么不同呢?我们来看下面这段代码
当结束进程时,exit函数会将缓冲区中的内容刷新,而_exit不会,这个现象其实可以推导出缓冲区不在操作系统中,因为exit就是封装的_exit,这个后面的章节会讲,这里先得出结论
三、进程等待
通过wait/waitpid,让父进程对子进程进行资源回收的等待过程
进程等待的原因:
- 子进程退出,父进程如果不管不顾,就可能造成僵尸进程的问题,造成内存泄漏(进程一旦变成僵尸状态,就无法被杀死)
- 父进程需要知道子进程的运行结果,通过进程等待获取子进程的退出信息---不是必须的,但是系统需要提供这样的功能
如何进行等待???
1.wait方法
pid_t wait(int*status);返回值:成功返回被等待进程pid,失败返回-1参数:输出型参数,获取子进程退出状态,不关心则可以设置成为NULL
代码一:
代码二:
上面两个代码说明两件事:
1.进程等待能回收子进程的僵尸状态
2.父进程必须在wait上进行阻塞等待,直到子进程运行结束变成僵尸状态,wait回收
2.waitpid方法
pid_ t waitpid(pid_t pid, int *status, int options);返回值:1.正常返回收集到的子进程的进程ID2.如果设置了选项WNOHANG,而发现没有子进程可收集,返回03.如果调用中出错,则返回-1,这时errno回被设置为相应的值来表明错误原因参数:pid:1) -1,等待任何一个子进程,与wait等效2)>0,等待进程ID和pid相等的子进程status:1) WIFEXITED(status): 若为正常终止子进程返回的状态,则为真(查看进程是否是正常退出)2)WEXITSTATUS(status): 若WIFEXITED非零,提取子进程退出码(查看进程的退出码)options:1)0:默认阻塞等待2)WNOHANG: 若pid指定的子进程没有结束,则waitpid()函数返回0,不予以等待。若正常结束,则返回该子进程的ID-----上面两个选项最重要,其他的options,请自行查阅文档
waitpid(-1,NULL,0)和wait(NULL)等价,这里就不演示了
下面来讲讲waitpid的后面两个参数(wait的参数和waitpid的第二个参数一样)
1.status
这个status输出型参数的值很奇怪,但是我将它用位运算分割成两个数字之后,我们就能理解了10是退出码,0代表进程没有出现异常,这个现象和它的底层设计有关
将10和0带入上面的规则,就会发现status=2560
上面演示的是正常退出的情况,下面演示一个进程异常被杀死的情况
这里再次强调:当进程异常时,退出码就没有意义了!!!
(扩展:父进程等待子进程处于阻塞状态时,本质其实是父进程的pcb链入了子进程pcb的等待队列。父进程需要获取到子进程的退出状态就意味着子进程的pcb中存有这两个数字,而wait和waitpid函数作为系统调用接口,将输出型参数status用这两个数字拼接后返回)
当然如果你对status的组成不是很了解,也可以用WIFEXITED和WEXITSTATUS这两个宏替代
异常的情况就留给读者自己去实验了
多个子进程的创建和等待
(这里仅是截取了最后的运行结果)
我们发现子进程的结束时间并非按创建的时间顺序,还是得看系统是如何调度的
2.options
0:阻塞等待,子进程不结束,不返回值,父进程只能一直等,不能做其他事情
WNOHANG:非阻塞等待,无论子进程是否结束,都返回结果,如果子进程结束,返回子进程ID,如果子进程没结束,返回0,一般需要重复调用,即轮询,父进程在等待时可以做自己的一些工作
非阻塞等待:
四、进程的程序替换
程序替换的用法和本质
当我们用fork创建子进程时,子进程执行的都是父进程代码块,如果我们要让子进程执行新的程序呢?即不再执行父进程的代码块,我们该怎么办?这就是程序替换的意义,我们用exec*这类的函数接口实现程序替换
下面,我们先来见识一下程序替换
我们在解决上面的问题之前,先看一下execl函数的声明
既然是替换程序,那么我们当然能执行被替换过来的ls命令,这个很容易理解,但是为什么第二个打印语句没有执行呢?因为代码被全部替换了,自然无法执行最后的打印语句。
那么代码被替换了,进程是不是也被替换了呢?
很显然,子进程的pid没有改变,也就是说没有创建新的进程,只是单纯的程序替换
(多进程的替换和写时拷贝原理一样,单一进程的程序替换就是将新程序覆盖原程序)
我们来说说这个execl函数的返回值,它只有在替换失败的时候才会右返回值,替换成功就没有返回值,其实想一想也确实合理,当它执行成功,后面的代码就不执行了,还要这个返回值干嘛呢?当然正常来说,它执行失败我们也不接收它的返回值,因为它执行任务失败我们直接结束进程就行
可能有人好奇它的返回值,这里演示一下
程序替换还有一些其他的接口,全是以exec开头的函数接口,如下
用法介绍
上面这些函数有兴趣可以自己回去试试,这里就不演示了,用法都很相似
既然能替换系统命令,那么能不能替换成我们写的程序呢?毕竟系统命令本质也是我们写的程序
下面我们来试试看
很显然,我们用exec*这种类型的接口实现了对我们自己写的程序的替换
那么我们能不能用它对其他语言所写的程序进行替换呢?
当然可以,因为它是进程的程序替换,无论是什么语言在Linux中运行都会变成进程,那么同为进程,为什么只有C++写的程序能被替换呢?所以exec*接口也能替换其他语言写的程序
下面写个bash脚本语言给大家见识一下
环境变量
1.当我们进行程序替换的时候,子进程对应的环境变量,是可以直接从父进程继承来的,证明如下
当我们在调用mytest这个进程的时侯,本质是bash创建了一个子进程执行mytest这个程序,而后mytest中又创建了子进程process,而环境变量具有全局属性,所以bash的子进程都能继承这些环境变量,而一旦mytest继承了这些环境变量,同理process也同样能继承mytest的环境变量,这只是猜测,下面是实验证明
2.环境变量被子进程继承是一种默认的行为,不受程序替换的影响
在学习进程地址空间时,我们学过命令行参数和环境变量也在进程地址空间中,当我们创建子进程时,环境变量当然也自动随着进程地址空间拷贝给了子进程,而程序替换并没有改变环境变量,说明程序替换不会改变环境变量
3.子进程获得的环境变量有两种方法:
a.从父进程原封不动的传递给子进程---1)什么都不做 2)通过execle/execvpe传递环境变量表environ
b.我们也能用execle/execvpe传递我们自己写的环境变量
c.如果想新增一些环境变量给子进程,同上,在父进程中putenv
讲了这么多,还有一个函数没介绍
在见过exec*的众多函数接口后,我们会发现他们的功能基本一样,只是单纯的使用方式不同,其实他们本质都是对execve这个系统接口的封装,以适应不同的场景需求而已