目录

父子进程之间的等待

介绍

为什么要有等待

内存泄漏

如何等待

介绍

pid_t wait (int* status)

介绍

status指针

示例

​编辑

pid_t waitpid (pid_t pid,int* status,int options)

pid

 options

WNOHANG -- 非阻塞等待

示例

status

查看status

status问题

正常退出时,恢复退出码

位运算

宏

进程崩溃,查看signal

引入

kill指令

示例 -- 野指针

示例 -- kill -9

为什么一定要通过上面的这些函数拿到退出信息

那么,这些问题wait / waitpid 是如何解决的呢?

---

父子进程之间的等待

介绍

通常用于实现协作和同步，以确保父进程等待子进程完成 / 等待子进程的某个事件

为什么要有等待

• 在某些情况下，父子进程需要在执行过程中相互协同工作，以确保程序的正确性和完整性
• 等待可以用于协调它们的活动，使它们按照某种特定的顺序执行任务
• 父进程可能需要等待这些子进程完成执行，以便获取子进程的结果、收集信息或继续执行其他操作
• 只有当父进程获取到子进程的退出状态信息时, 才会回收子进程资源(所以,如果父进程提前退出,将会造成子进程的资源泄漏)

内存泄漏

• 这里的内存泄漏是指进程的task_struct还保留在内存中(也就是系统资源泄漏)
• task_struct由os维护,其他人没有权限来释放,只能等待父进程回收 / 父进程退出后由init进程回收
• 而我们平常说的内存泄漏是指进程在堆上开辟的空间没有被释放
• 但其实一旦进程退出,这些由语言申请的空间都会被释放掉

如何等待

介绍

 头文件:

pid_t wait (int* status)

介绍

• 用于父进程等待子进程的终止,并获取其退出状态
• 如果当前没有子进程终止，父进程将被阻塞，等待一个子进程终止(也就是阻塞式等待)
• 当一个子进程终止后，父进程会解除阻塞，并获取已终止子进程的pid(返回值),如果没有子进程终止,返回-1

status指针

• 用于存储子进程的退出状态信息
• 当该位置有参数时,由os提供该值
• 如果不关心子进程的退出状态，可以传递NULL

示例

下面的代码流程是:

• 创建一个子进程,子进程打印信息后睡眠5s,
• 而父进程打印信息后睡眠7s,再等待进程状态变化
• (其中的2s内可以看到子进程处于僵尸状态)
• 后调用wait函数,用以回收已终止子进程的资源

可以看到,我们成功等待到了子进程:

 

子进程24295从僵尸状态Z+ -> 进程退出了,说明父进程等待子进程成功后,就释放掉了子进程的资源

pid_t waitpid (pid_t pid,int* status,int options)

pid

• 如果为-1,则代表等待任意一个子进程终止(与wait()等价)
• >0,它在等待指定的子进程

 options

默认是0,进行阻塞式等待

• 此时父进程不做任何事,在等待队列中等待子进程的状态改变
• 不占用cpu的时间片,这期间调度器调用其他可用进程
• 阻塞的上层表现 -- 该进程无反应(因为cpu没有调度它)

WNOHANG -- 非阻塞等待

• 是宏定义(系统提供的大写标识位:一般都是宏定义,将没有特殊意义的数字定义成宏,使用时更加清晰)
• 如果指定的子进程状态未改变，立即返回0 
• 此时,父进程就可以执行waitpid后面的代码了(可以在等待的过程中完成一些小的工作模块)
• 父进程在继续执行其他任务的同时,周期性地调用waitpid函数,以不断检查子进程的状态,从而及时获取子进程的退出状态

示例

可以看到,在父进程在等待子进程的过程中,依然在工作中

最终成功等待到子进程

 

status

和wait中的status用法一样

如果为waitpid(-1,NULL,0),则与wait(NULL)等价,看到的结果相同

查看status

如果我们尝试查看status呢?就可以使用waitpid(ret,&status,0):

我们让子进程睡眠5s后,带着退出码=2023退出,然后由父进程等待子进程退出,拿到退出码

 但是,结果似乎并不是我们想象中的那样(虽然子进程成功退出了,但是status的值很奇怪捏):

拿到的退出码怎么会是59136呢?

status问题

为什么上面的代码会出现值不一样的情况呢?

实际上status在函数内部并不是当做一个整数来对待,而是拆成32位bit位

其中低16位是我们需要了解的

正常退出时,恢复退出码

• 如果程序执行完毕 (可以通过 宏(WIFEXITED) / 退出码 来判断是否正常退出)
• 它会将实际的退出码放入[status的低16位]的后8位,然后将该数作为status的值
• 所以我们得到的status会比设置的退出码(2023)大很多

位运算

• 可以通过位运算的方式,将原本的退出码还原 (status>>8) & 0x0000 00ff
• 向右移8位是为了将退出状态移到该数的低8位,然后按位与拿到低8位
• 
• 

宏

• 也可以通过宏拿到该值 (WEIXTSTATUS)
• 
• 

进程崩溃,查看signal

引入

• 如果进程崩溃提前终止了呢?这时的退出状态就没有意义了(会是0)
• 其实想一想,运行的程序崩溃 本质上就是 os将这个进程杀死了
• 那它是如何在茫茫进程中,单单选中了崩溃的进程把它杀死了呢?
• 是通过程序发送信号通知os的

kill指令

• 实际上,我们的kill指令就是通过os向进程发送信号,来对进程进行操作
• 
• 其中,信号是有编号的,1-31是普通信号,我们要学的也就是这31个信号
• 然后,通过将 信号 放入 status的低7位 (第8位是core dump标志,在gdb调试崩溃程序中用到)
• 
• 我们可以通过按位与拿到低7位(& 0x0000 007f)

示例 -- 野指针

• 
• 

示例 -- kill -9

除了出现错误使程序崩溃,也可以是外力直接杀掉

• 当子进程在死循环时,可以使用kill指令杀掉它(通过发送信号)
• 

为什么一定要通过上面的这些函数拿到退出信息

• 如果设置为全局变量呢?似乎可以拿到
• 但其实,因为你要根据不同的判断条件来修改退出码,所以此时必定发生写时拷贝
• 那么就会导致父子进程中的那个全局变量实际上有两个,父进程无法拿到子进程的变量,进程之间具有独立性

• 除此之外,信号你又该如何拿到呢?

那么,这些问题wait / waitpid 是如何解决的呢?

• 首先,那些退出信息也是数据,它就被存放在描述进程的pcb中
• 还记得僵尸进程吗?
• 为什么它有害,就是因为它的task_struct还保留在内存中,占用着资源
• 必须要由父进程拿到子进程的退出码,才能释放它
• 但是,进程之前不是有独立性吗?父进程是如何拿到子进程中的退出码的?
• 实际上是由os完成的
• os会自动回收子进程的资源,并将退出状态信息传递给父进程
• 那么,wait和waitpid也是一样的道理,也是os完成实际的工作

• wait和waitpid是系统调用,它是由os提供的接口
• 因此由os维护的task_struct自然可以被自己的接口调用啦!!!
• 所以,父进程是无法拿到子进程内部的信息的,但是os帮它拿到了