标签:
转自 http://blog.csdn.net/todd911/article/details/17115365
早期的UNIX系统的一个特性是:如果进程在执行一个低速系统调用而阻塞期间捕捉到一个信号,该系统调用就被终端不再
继续执行。该系统调用返回出错,其errno被设置为EINTR。
为了支持这种特性,将系统调用分成两类:低速系统调用和其他系统调用。低速系统调用是可能会使进程永远阻塞的一类
系统调用:
1.在读某些类型的文件(管道,终端设备以及网络设备)时,如果数据并不存在则可能会使调用者永远阻塞。
2.在写这些类型的文件时,如果不能立即接受这些数据,则会使调用者永远阻塞。
3.打开某些类型的文件,在某些条件发生之前也可能会使调用者阻塞(例如,打开终端设备,它要等待直到所连接的调制
解调器应答了电话)
4.pause函数和wait函数
5.某些ioctl函数
6.某些进程间通信函数。
与被中断的系统调用相关的问题是必须显式地处理出错返回。典型的代码如下:
为了帮助应用程序使其不必处理被中断的系统调用,4.2BSD引入了某些中断系统调用的自动重启动。自动重启动的系统调用包括:
ioctl,read,readv,write,writev,wait和waitpid。其中前5个函数只有对低速设备进行操作时才会被信号终端。而wait和waitpid
在捕捉到信号时总是被中断。
POSIX.1允许实现重启动系统调用,但是这并不是必须的。XSI将SA_RESTART定义为对sigaction的XSI扩展,允许应用程序要求
重启被中断的系统调用。
实践:
运行结果:
root@-virtual-machine:~# ./a.out
^Cint handler 2
read error Interrupted system call
read -1 bytes, content is
root@virtual-machine:~#
可见read直接返回,不会重启。
下面我们将
act.sa_flags |= SA_RESTART;
的注释打开,再次运行:
root@virtual-machine:~# ./a.out
^Cint handler 2
^Cint handler 2
^Cint handler 2
^Cint handler 2
^Cint handler 2
^Cint handler 2
123
read 4 bytes, content is 123
root@virtual-machine:~#
按了多次ctrl c,read也没有返回,因为read自动重启了。 //运行的结果跟这个不一样啊...???
标签:
原文地址:http://www.cnblogs.com/QingCHOW/p/4601832.html