在linux编程接口书中,(p.1367)
在使用信号驱动的I/O时,也可以考虑饥饿问题,因为它还提供了边缘触发的通知机制。相反,饥饿考虑并不一定适用于使用级别触发通知机制的应用程序。这是因为我们可以使用具有级别触发通知的阻塞文件描述符,并使用一个循环,该循环不断检查描述符是否就绪,然后在再次检查就绪文件描述符之前对就绪描述符执行一些I/O操作。
我不明白这个“阻塞”部分意味着什么。我认为我们使用阻塞I/O还是非阻塞I/O是不相关的(在本章的早期,作者还说,无论是水平触发通知还是边缘触发通知,通常都使用非阻塞I/O )。
发布于 2012-01-24 14:49:43
那么,IO,嗯?嗯,IO是“处理事情”,所以我们可以用一个人类的比喻。想象一下,你是一个系统的过程,为你的老板做一些事情。
然后阻止IO就像去看牙医或者与客户面对面地见面。在这两种情况下,当你去做这件事,你离开你的办公桌,所以完全无法做任何其他事情,直到你回到你的办公桌。很有可能,你会在候诊室浪费一些时间,或者在会上闲聊/等人出现。
阻塞IO就像这样--阻塞IO“牺牲”(我这么说是因为你失去了线程,实际上)线程对所讨论的任务。当它被阻塞时,你不能将它用于任何其他目的--它在等待那个IO发生。
相比之下,非阻塞IO就像打电话一样。当你在打电话的时候,你可以参与这个IO,同时在堆栈溢出上写一个答案!这种IO被认为是异步的,因为您接受一个IO请求并开始处理它,但是在它们完成时可以处理其他请求。
现在,我最喜欢的资源是这里的c10k问题页面。我想说你是对的-- 99%的时间你要使用非阻塞IO (事实上,你的操作系统一直在为你执行非阻塞IO ),这主要是因为对每个传入的IO任务使用一个完整的线程是非常低效率的,即使在Linux中,线程和进程是相同的(任务),并且相当轻量级。
边缘触发通知类型和水平触发通知类型之间的区别可能更多地适用于非阻塞连接,因为它无论如何都与阻塞情况无关。据我所知,边缘触发的通知只在上次请求状态更新时有新数据时标记描述符为就绪,而级别触发则标记在有可用数据时随时可以处理的描述符。这意味着边缘触发的接口是被认为更棘手一些,因为您必须使用当您看到传入数据时,处理它,因为您不会再次收到通知。理论上,这应该更有效(更少的通知)。
因此,tl;dr - edge与级别准备与阻塞与非阻塞设计略有不同,即有几种方法可以执行非阻塞IO,而实际上只有一种方法可以执行阻塞IO。
https://stackoverflow.com/questions/8125913
复制相似问题