信号中断与慢系统调用

Slow system call

该术语适用于那些可能永远阻塞的系统调用。永远阻塞的系统调用是指调用永远无法返回,多数网络支持函数都属于这一类。如:若没有客户连接到服务器上,那么服务器的accept调用就会一直阻塞。

慢系统调用可以被永久阻塞,包括以下几个类别:

(1)读写‘慢’设备(包括pipe,终端设备,网络连接等)。读时,数据不存在,需要等待;写时,缓冲区满或其他原因,需要等待。读写磁盘文件一般不会阻塞。

(2)当打开某些特殊文件时,需要等待某些条件,才能打开。例如:打开中断设备时,需要等到连接设备的modem响应才能完成。

(3)pause和wait函数。pause函数使调用进程睡眠,直到捕获到一个信号。wait等待子进程终止。

(4)某些ioctl操作。

(5)某些IPC操作。

EINTR错误产生的原因

早期的Unix系统,如果进程在一个慢系统调用(slow system call)中阻塞时,当捕获到某个信号且相应信号处理函数返回时,这个系统调用被中断,调用返回错误,设置errno为EINTR(相应的错误描述为“Interrupted system call”)。

怎么看哪些系统条用会产生EINTR错误呢?用man啊!

如何处理被中断的系统调用

既然系统调用会被中断,那么别忘了要处理被中断的系统调用。有三种处理方式:

◆ 人为重启被中断的系统调用

◆ 安装信号时设置 SA_RESTART属性(该方法对有的系统调用无效)

◆  忽略信号(让系统不产生信号中断)

慢系统调用(slow system call)会被信号中断,系统调用函数返回失败,并且errno被置为EINTR(错误描述为“Interrupted system call”)。

处理方法有以下三种:①人为重启被中断的系统调用;②安装信号时设置 SA_RESTART属性;③忽略信号(让系统不产生信号中断)。

有时我们需要捕获信号,但又考虑到第②种方法的局限性(设置 SA_RESTART属性对有的系统无效,如msgrcv),所以在编写代码时,一定要“人为重启被中断的系统调用”。

时间: 2024-10-16 11:10:37

信号中断与慢系统调用的相关文章

关于信号中断与慢系统调用的深度发现

这段时间在看Unix网络编程卷1,在5.9节处理SIGCHLD信号,关于处理僵死进程第四步如下写道:信号是在父进程阻塞于慢系统调用(accept)时由父进程捕获的,内核就会使慢系统调用(accept)返回一个EINTR错误. 看到上面那段落的时候,想到我前段时间写网络服务器遇到的问题,链接地址:http://bbs.csdn.net/topics/391032981,其实里面也有我关于这方面问题的困惑. 总结一下我论坛的那个问题,其实我无论如何是不能通过信号中断,测试epoll_wait出错er

信号中断与异步信号中断安全编程

1.什么是中断? 1.1.什么是中断 外围设备的速度远低于CPU的速度,所以为提高CPU计算效率,现代计算机变内核主动为硬件主动,只在硬件需要的时候才发送信号,通知内核来处理数据.这样外围设备与内核的协作方式即为中断机制.而设备发送的信号即为中断,其本质为一种特殊的电信号. 硬中断处理流程: 1.各外围设备与中断管理器各输入引脚相连: 2.中断管理器与CPU之间只存在一条中断管线: 3.设备发送一个中断到中断管理器: 4.中断管理器发送对应电信号给CPU. 5.CPU中断当前工作,开始处理中断,

一、进程与信号之进程相关系统调用

进程调用函数wait(),waitpid() #include <sys/types.h> #include <sys/wait.h> pid_t wait(int *status) //等待所有子进程,返回任一终止子进程的状态,阻塞方式 pid_t waitpid(pid_t pid,int *status,int options) //指定子进程pid等待终止返回,option设置是否阻塞 status参数 为空时,代表任意状态结束的子进程,若不为空,则代表指定状态结束的子进程

转 linux 之信号

APUE讲信号真是生涩,着实读者无趣,如是找一篇总结比较好的博客. 原文http://blog.chinaunix.net/uid-24774106-id-4061386.html Linux编程,信号是一个让人爱恨交加又不得不提的一个领域.最近我集中学习了Linux的signal相关的内容,分享出来,也为防止自己忘记.     信号的本质是异步.异步一这个词,听着高端大气上档次,又让人云山雾绕,其则不然.其实我们想想,我们这个世界是异步的,每个人干事儿,并不总是 A->B->C->D这

linux_api之信号

本片索引: 1.引言 2.信号 3.程序启动 4.signal函数 5.系统调用的中断和系统调用的重启(了解) 6.可再入与不可再入函数(了解) 7.kill函数和raise函数 8.alarm函数和pause函数 9.信号的发送.接收和处理的过程 10.信号集设置函数和sigprocmask函数 11.sigpending函数 12.sigaction函数 13.sigsuspend函数 14.abort函数 15.sleep函数           1.引言 信号是一种软件中断,与之相对应的

Linux下的进程与线程(二)—— 信号

Linux进程之间的通信: 本文主要讨论信号问题. 在Linux下的进程与线程(一)中提到,调度器可以用中断的方式调度进程. 然而,进程是怎么知道自己需要被调度了呢?是内核通过向进程发送信号,进程才得以知道的. Linux系统的进程之间是通过信号来通信的. 程序员在Shell上显式地发送信号使用的是kill命令,原型如下: kill -sigid [-]pid 其中, sigid指示的是信号的id,pid前若有-,则pid代表的为进程组id,否则pid代表的为进程id kill函数也有相同的作用

Linux编程---信号处理

信号是一种异步的进程间通信的方式.但是这种通知方式能交换的信息很少.只能说给一个事件的标志.类似单片机中的中断,强迫进程停止做当前应当做的事情,而去执行中断执行程序. 信号的产生有如下几种: 1.用户按下了某个终止键,如ctrl-\或ctrl-c.是由终端程序向当前进程发送一个中断信号. 2.程序异常.比如除零错误. 3.kill函数向其发送了一个终止信号 4.进程向自己发送信号.如进程调用alarm函数. 5.企图读写终端的后台进程会得到作业的控制信号SIGTTIN或SIGTOU. 6.当进程

比较好的进程篇总结(转)

原文:http://www.cnitblog.com/guopingleee/archive/2007/09/18/33687.html 一.多进程程序的特点    由于UNIX系统是分时多用户系统, CPU按时间片分配给各个用户使用, 而在实质上应该说CPU按时间片分配给各个进程使用, 每个进程都有自己的运行环境以使得在CPU做进程切换时不会"忘记"该进程已计算了一半的"半成品". 以DOS的概念来说, 进程的切换都是一次"DOS中断"处理过程

socket中的函数遇见EINTR的处理【转】

转自:http://blog.chinaunix.net/uid-21501855-id-4490453.html 这几天,写服务器代码过程当中,遇见EINRT信号的问题,我是借鉴 <unp >,采用continue或者goto again循环解决的.但是感觉这个还是很有必要记录一下.网络上查找到的信息很多.下面是我查找到的和EINTR有关的介绍: 1  http://blog.csdn.net/yanook/article/details/7226019  慢系统调用函数如何处理中断信号EI