在linux编程接口书中，（p.1367）
使用信号驱动的I / O时，也可以应用饥饿注意事项， 因为它还提供了边缘触发的通知机制。通过 相比之下，饥饿的考虑不一定适用于 采用级别触发通知机制的应用程序。这个 是因为我们可以使用阻止文件描述符 级别触发通知并使用连续检查的循环 准备就绪的描述符，然后在就绪时执行一些I / O. 在再次检查就绪文件描述符之前的描述符。
我不明白这个'阻塞'部分意味着什么。我认为我们是否使用阻塞I / O或非阻塞I / O是无关紧要的。 （作者还在本章的前面部分说过，无论级别触发或边缘触发通知如何，都会使用非阻塞I / O）
答案 0 :(得分：1)
SO，IO嗯？嗯，IO是“处理事物”所以我们可以用人类的比喻。想象一下，你是一个系统的过程，为你的老板完成任务。
然后阻止IO就像去看牙医或面对面与客户会面。在这两种情况下，当你去参加那个活动时，你离开你的办公桌，所以在你回到办公桌之前完全无法做任何其他事情。有可能，你会在等候室里浪费一些时间或在会议中闲聊，等待人们出现。
阻止IO就是这样 - 阻止IO“牺牲”（我说这是因为你有效地失去了线程）线程到有问题的任务。当它被阻止时，你不能将它用于任何其他目的 - 它正在等待IO发生。
相反，非阻塞IO就像在电话上一样。当您在通话时，您可以在Stack Overflow上写下答案时参与该IO！这种IO被称为异步 - 因为您接受IO请求并开始处理它，但可以在完成时处理其他请求。现在，我最喜欢这类资源的是c10k problem页面。我说你是对的 - 99％的时间你会使用非阻塞IO（事实上，你的操作系统一直在为你进行非阻塞IO），主要是因为每个都使用一个完整的线程传入的IO任务非常低效，即使在Linux中，线程和进程是相同的（任务）并且相当轻量级。
边缘触发和水平触发通知类型之间的差异可能更多地适用于非阻塞连接，因为它无论如何都与阻塞情况无关。据我了解，边缘触发通知仅在上次请求状态更新时有新数据时将描述符标记为就绪，而触发的级别标记描述符，只要有可用数据就可以处理。这意味着边缘触发的接口为considered a bit more tricky，因为您必须handle the incoming data when you see it，因为您不会再次收到通知。从理论上讲，这应该更有效（通知更少）。
所以，tl; dr-edge vs level readyiness对阻塞与非阻塞设计的考虑略有不同，即有几种方法可以进行非阻塞IO，只有一种方法可以阻塞IO。