求助：网络编程中，read函数处于阻塞状态时的信号中断响应问题

Demoes

网络编程中，read函数处于阻塞状态，此时被信号中断，但为什么中断处理后，read还继续阻塞？

看书上说，read被中断后会返回-1，不会再阻塞，但我使用的read怎么还继续阻塞呢？
有没有办法让read被信号中断后退出阻塞的？

我使用的环境是：RedHat Linux 8.0，gcc也是RedHat自带的，忘了多少版本。收到的信号是SIGALRM.

现在想到的办法是：信号处理函数中，关掉socket连接的可读属性，让read出错退出，之后再打开socket连接的可读属性。

不知大家怎么看？

feasword

这种需求应该用select来做
我也想知道read的阻塞具体是怎么实现的,关于信号那个问题,应该也是判断了errno==EINTER吧

Demoes

我在read函数后判断了errno==EINTR，但是read函数根本没退出阻塞，直到接收完数据才退出的，因此read的返回值也不会<0，也就不会执行判断errno是否==EINTR了。

嗯，select会比较适合在这种场合

谢谢

langue

额，select 和 poll/epoll 都能做到。

关于具体的机制，可以参考系统的源代码。《UNIX 操作系统设计》一书，也可供参考之用。

longshort

一般情况下，可以设置一个标号来返回到read：

1. 
   
2. ...
   
3. do_read_begin:
   
4. if(read(...)==-1) {
   
5.         switch(errno) {
   
6.         case EINTR:
   
7.                 <中断处理>;
   
8.                 goto do_read_begin;
   
9.         ...
   
10.                 }
    
11.         }
    
12. ...
    

复制代码

只要errno等于EINTR，那就一定是中断引起，处理完中断就可以直接返回标号，不会引起其它问题，在这里用goto是直接而了当的。