标签：发送 利用 nbsp 处理程序 === 变化 一个 僵死 alt
Linux下常用的5中IO 模型
阻塞I/O
当上层应用app1调用recv系统调用时，如果对等方没有发送数据（缓冲区没有数据），上层应用app1将阻塞（默认行为，被linux内核阻塞）；当对等方发送了数据，linux内核recv端缓冲区，有数据后，内核会把数据copy给用户空间。然后上层应用app1解除阻塞，执行下一步操作。
非阻塞I/O
上层应用程序app2将套接字设置成非阻塞模式。上层应用程序app2轮询调用recv函数，接受数据。若缓冲区没有数据，上层程序app2不会阻塞，recv返回值为-1，错误码是EWOULDBLOCK。上层应用程序不断轮询有没有数据到来。会造成上层应用忙等待。大量消耗CPU。很少直接用。应用范围小，一般和selectIO复用配合使用。
I/O复用
上层应用程序app3调用select机制（该机制有linux内核支持，避免了app3忙等待。），进行轮询文件描述符的状态变化。当select管理的文件描述符没有数据（或者状态没有变化时），上层应用程序app3也会阻塞。好处select机制可以管理多个文件描述符。select可以看成一个管理者，用select来管理多个IO。一旦检测到的一个I/O或者多个IO，有我们感兴事件，发生，select函数将返回，返回值为检测到的事件个数。进而可以利用select相关api函数，操作具体事件。select函数可以设置等待时间，避免了上层应用程序app3，长期僵死。和阻塞IO模型相比，selectI/O复用模型相当于提前阻塞了。等到有数据到来时，再调用recv就不会发生阻塞。
信号驱动I/O
上层应用程序app4建立SIGIO信号处理程序。当缓冲区有数据到来，内核会发送信号告诉上层应用程序app4。上层应用程序app4接收到信号后，调用recv函数，因缓冲区有数据，recv函数一般不会阻塞。这种用于模型用的比较少，属于典型的“拉模式”。即：上层应用app4,需要调用recv函数把数据拉进来。信号模型的问题在于信号的递达是需要时间的，信号的处理也是有延迟的，如果在没有处理之前，数据发生了修改，就很难进行处理了，
异步I/O
上层应用程序app5调用aio_read函数，同时提交一个应用层的缓冲区buf；调用完毕后，不会阻塞。上层应用程序app5可以继续其他任务。当tcpip协议缓冲区有数据时，linux主动的把内核数据copy到用户空间。然后再给上层应用app5发送信号；告诉app5数据有了，赶快处理吧！这是典型的“推模式”。是效率最高的一种形式，上层应用程序app5有异步处理的能力（在linux内核的支持下，言外之意：处理其他任务的同时，也可支持IO通讯）。异步I/O指的是什么？上层应用程序app5，在也可以干别的活的时，可以接收数据（接受异步通信事件。===）异步命令来源）。与信号驱动IO模型，上层应用程序app5不需要调用recv函数。
标签：发送 利用 nbsp 处理程序 === 变化 一个 僵死 alt
原文地址：https://www.cnblogs.com/randyniu/p/9159453.html
