为什么IO多路复用需要采用非阻塞式IO

近段时间开始学习《Unix网络编程》,代码实现了一个简单的IO多路复用+阻塞式的服务端,在学习了非阻塞式IO后,有一个疑问,即:

假如调用了select,并且关注了几个描述字,当关注的描述字可读时,select成果返回并告诉我对应套接口已可读,此时采用阻塞式read或非阻塞式read去读套接口有何区别,既然已经告诉套接字可读,调用read怎么还会发生阻塞。即本问题,为什么IO多路复用需要采用非阻塞式IO。

当时理解不深,不知道该问题存在原因,第二天偶然刷知乎,刷到了这个问题。现解释如下:

1、首先看下man select解释:

Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.
当某个socket接收缓冲区有新数据分节到达,然后select报告这个socket描述符可读,但随后,协议栈检查到这个新分节检验和错误,然后丢弃这个分节,这时候调用read则无数据可读,如果socket没有被设置nonblocking,此read将阻塞当前线程。
 
即select可能存在如下问题:当新数据到达描述符,select返回描述符可读,但Linux内核协议栈检查到新数据包的校验和错误,故丢弃该数据,采用阻塞式IO去读该套接口,无数据可读,则当前进程阻塞。
2、第二种解释有:
一种典型场景,惊群现象:当采用多线程方式通过select或epoll监听套接字,当新连接到达,则所有监听套接字的线程会通过select被唤醒,但是最终只有一个线程会通过accept与这个新连接建立握手关系,如果采用了阻塞式IO,则其余所有没有接收到accept连接的线程会阻塞。
原文地址:https://www.cnblogs.com/scu-cjx/p/7735542.html