Linux---进程控制

一、进程创建

fork函数

在Linux中fork函数是非常重要的函数,它从已存在进程中创建一个新进程,原进程为父进程

Linux---进程控制_第1张图片

fork函数的功能:

  • 分配新的内存和内核数据结构给子进程
  • 将父进程部分数据结构内容拷贝至子进程
  • 添加子进程到系统的进程列表中
  • fork返回,开始调度器调度 

fork函数的返回值:

  • 子进程返回0
  • 父进程返回子进程的pid
  • 创建进程失败返回

Linux---进程控制_第2张图片

 写实拷贝

在进程地址空间中,我们解释了父子进程的数据相同地址不同值的问题,那么现在我们来谈谈OS是具体怎么实现的,下面给大家画个草图

Linux---进程控制_第3张图片

fork的常规用法

  • 一个父进程希望复制自己,使父子进程同时执行不同的代码段。例如,父进程等待客户端请求,生成子进程来处理请求
  • 一个进程要执行一个不同的程序。例如子进程从fork返回后,调用exec函数

fork调用失败的原因

  • 系统中有太多的进程
  • 实际用户的进程数超过了限制

 二、进程终止

进程退出场景

  • 代码运行完毕,结果正确
  • 代码运行完毕,结果不正确
  • 代码异常终止

为什么要介绍这个?因为系统创建进程本质是让进程去完成一些工作,那么系统当然有必要去了解工作的结果,如果成功了,那么万事大吉,如果代码错误,不管是代码运行完毕结果错误还是出现异常提前终止,操作系统都需要知道原因,那么如何知道进程失败的原因呢?

1.代码运行完毕,结果不正确

相信大家在写C语言的时候,main方法里总是会写return 0;这个语句,现在我们应该明白,其实这就是告诉父进程,该进程工作顺利完成,同时我们也或多或少在控制台的黑窗口中见过某某程序返回值不为0的情况。这些返回值统一叫做退出码,对应一些数字,而每一个数字对应一个字符串

Linux---进程控制_第4张图片

当然这个退出码也是可以自定义的

这个和C语言中学的errno(错误码)这个全局变量很相似(大家可以去查查C的文档),只不过退出码是记录进程跑完后的结果是否正确及错误的原因,错误码记录库函数/系统接口,即函数运行失败的原因

Linux---进程控制_第5张图片

 2.代码异常终止

Linux---进程控制_第6张图片

Linux---进程控制_第7张图片 上面两个程序都是异常终止,操作系统检测到进程异常通过信号直接杀掉进程(因为操作系统是进程的管理者)

Linux---进程控制_第8张图片

 总结:

1.进程是否异常,看有没有收到信号

2.进程运行结果是否正确和错误的原因,看退出码

(进程异常结束后,退出码就没有意义了)

3.进程常见的退出方法

正常终止(可以通过echo $?查看进程的退出码):

  • 从main返回(执行return n等同于执行exit(n),因为调用main的运行时函数会将main的返回值当做 exit的参数)---这里的return仅限于main函数中的,其他函数的return不具有结束进程的功能,这里就不做过多介绍了
  • 调用exit(库函数)
  • 调用_exit(系统接口)

1.exit---库函数

Linux---进程控制_第9张图片

Linux---进程控制_第10张图片

 2._exit---系统调用接口

Linux---进程控制_第11张图片

Linux---进程控制_第12张图片

上面的代码运行结果和exit一样,就是将exit函数换成了_exit函数,结论和上面一样

那么这两个函数有什么不同呢?我们来看下面这段代码

Linux---进程控制_第13张图片

当结束进程时,exit函数会将缓冲区中的内容刷新,而_exit不会,这个现象其实可以推导出缓冲区不在操作系统中,因为exit就是封装的_exit,这个后面的章节会讲,这里先得出结论

三、进程等待

通过wait/waitpid,让父进程对子进程进行资源回收的等待过程

进程等待的原因:

  1. 子进程退出,父进程如果不管不顾,就可能造成僵尸进程的问题,造成内存泄漏(进程一旦变成僵尸状态,就无法被杀死)
  2. 父进程需要知道子进程的运行结果,通过进程等待获取子进程的退出信息---不是必须的,但是系统需要提供这样的功能

 如何进行等待???

1.wait方法

pid_t wait(int*status);
返回值:
成功返回被等待进程pid,失败返回-1
参数:
输出型参数,获取子进程退出状态,不关心则可以设置成为NULL

代码一:

Linux---进程控制_第14张图片

Linux---进程控制_第15张图片

代码二:

Linux---进程控制_第16张图片

Linux---进程控制_第17张图片

上面两个代码说明两件事:

1.进程等待能回收子进程的僵尸状态

2.父进程必须在wait上进行阻塞等待,直到子进程运行结束变成僵尸状态,wait回收

2.waitpid方法

pid_ t waitpid(pid_t pid, int *status, int options);
返回值:
1.正常返回收集到的子进程的进程ID
2.如果设置了选项WNOHANG,而发现没有子进程可收集,返回0
3.如果调用中出错,则返回-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

Linux---进程控制_第18张图片

这个status输出型参数的值很奇怪,但是我将它用位运算分割成两个数字之后,我们就能理解了10是退出码,0代表进程没有出现异常,这个现象和它的底层设计有关

Linux---进程控制_第19张图片

 将10和0带入上面的规则,就会发现status=2560

上面演示的是正常退出的情况,下面演示一个进程异常被杀死的情况

Linux---进程控制_第20张图片Linux---进程控制_第21张图片

这里再次强调:当进程异常时,退出码就没有意义了!!!

(扩展:父进程等待子进程处于阻塞状态时,本质其实是父进程的pcb链入了子进程pcb的等待队列。父进程需要获取到子进程的退出状态就意味着子进程的pcb中存有这两个数字,而wait和waitpid函数作为系统调用接口,将输出型参数status用这两个数字拼接后返回)

当然如果你对status的组成不是很了解,也可以用WIFEXITED和WEXITSTATUS这两个宏替代

Linux---进程控制_第22张图片

异常的情况就留给读者自己去实验了 

多个子进程的创建和等待

Linux---进程控制_第23张图片

Linux---进程控制_第24张图片

(这里仅是截取了最后的运行结果)

我们发现子进程的结束时间并非按创建的时间顺序,还是得看系统是如何调度的

2.options

0:阻塞等待,子进程不结束,不返回值,父进程只能一直等,不能做其他事情

WNOHANG:非阻塞等待,无论子进程是否结束,都返回结果,如果子进程结束,返回子进程ID,如果子进程没结束,返回0,一般需要重复调用,即轮询,父进程在等待时可以做自己的一些工作

 非阻塞等待:

Linux---进程控制_第25张图片

Linux---进程控制_第26张图片

 四、进程的程序替换

程序替换的用法和本质

当我们用fork创建子进程时,子进程执行的都是父进程代码块,如果我们要让子进程执行新的程序呢?即不再执行父进程的代码块,我们该怎么办?这就是程序替换的意义,我们用exec*这类的函数接口实现程序替换

下面,我们先来见识一下程序替换

Linux---进程控制_第27张图片

我们在解决上面的问题之前,先看一下execl函数的声明

Linux---进程控制_第28张图片

既然是替换程序,那么我们当然能执行被替换过来的ls命令,这个很容易理解,但是为什么第二个打印语句没有执行呢?因为代码被全部替换了,自然无法执行最后的打印语句。

那么代码被替换了,进程是不是也被替换了呢?

Linux---进程控制_第29张图片

Linux---进程控制_第30张图片

很显然,子进程的pid没有改变,也就是说没有创建新的进程,只是单纯的程序替换

(多进程的替换和写时拷贝原理一样,单一进程的程序替换就是将新程序覆盖原程序)

我们来说说这个execl函数的返回值,它只有在替换失败的时候才会右返回值,替换成功就没有返回值,其实想一想也确实合理,当它执行成功,后面的代码就不执行了,还要这个返回值干嘛呢?当然正常来说,它执行失败我们也不接收它的返回值,因为它执行任务失败我们直接结束进程就行

可能有人好奇它的返回值,这里演示一下

Linux---进程控制_第31张图片

Linux---进程控制_第32张图片

程序替换还有一些其他的接口,全是以exec开头的函数接口,如下

Linux---进程控制_第33张图片

用法介绍

Linux---进程控制_第34张图片

上面这些函数有兴趣可以自己回去试试,这里就不演示了,用法都很相似 

既然能替换系统命令,那么能不能替换成我们写的程序呢?毕竟系统命令本质也是我们写的程序

下面我们来试试看

Linux---进程控制_第35张图片

Linux---进程控制_第36张图片

Linux---进程控制_第37张图片

Linux---进程控制_第38张图片

很显然,我们用exec*这种类型的接口实现了对我们自己写的程序的替换

那么我们能不能用它对其他语言所写的程序进行替换呢?

当然可以,因为它是进程的程序替换,无论是什么语言在Linux中运行都会变成进程,那么同为进程,为什么只有C++写的程序能被替换呢?所以exec*接口也能替换其他语言写的程序

下面写个bash脚本语言给大家见识一下

Linux---进程控制_第39张图片

 Linux---进程控制_第40张图片Linux---进程控制_第41张图片

环境变量

1.当我们进行程序替换的时候,子进程对应的环境变量,是可以直接从父进程继承来的,证明如下

Linux---进程控制_第42张图片

Linux---进程控制_第43张图片

Linux---进程控制_第44张图片

当我们在调用mytest这个进程的时侯,本质是bash创建了一个子进程执行mytest这个程序,而后mytest中又创建了子进程process,而环境变量具有全局属性,所以bash的子进程都能继承这些环境变量,而一旦mytest继承了这些环境变量,同理process也同样能继承mytest的环境变量,这只是猜测,下面是实验证明

Linux---进程控制_第45张图片

Linux---进程控制_第46张图片

2.环境变量被子进程继承是一种默认的行为,不受程序替换的影响

在学习进程地址空间时,我们学过命令行参数和环境变量也在进程地址空间中,当我们创建子进程时,环境变量当然也自动随着进程地址空间拷贝给了子进程,而程序替换并没有改变环境变量,说明程序替换不会改变环境变量

3.子进程获得的环境变量有两种方法:

a.从父进程原封不动的传递给子进程---1)什么都不做   2)通过execle/execvpe传递环境变量表environ

b.我们也能用execle/execvpe传递我们自己写的环境变量

c.如果想新增一些环境变量给子进程,同上,在父进程中putenv

Linux---进程控制_第47张图片

Linux---进程控制_第48张图片

Linux---进程控制_第49张图片

讲了这么多,还有一个函数没介绍

在见过exec*的众多函数接口后,我们会发现他们的功能基本一样,只是单纯的使用方式不同,其实他们本质都是对execve这个系统接口的封装,以适应不同的场景需求而已

你可能感兴趣的:(linux,运维,服务器)