linux - 文件描述符饥饿和阻塞文件描述符

Question

在 linux 编程接口(interface)书中，(p.1367)

Starvation considerations can also apply when using signal-driven I/O, since it also presents an edge-triggered notification mechanism. By contrast, starvation considerations don’t necessarily apply in applications employing a level-triggered notification mechanism. This is because we can employ blocking file descriptors with level-triggered notification and use a loop that continuously checks descriptors for readiness, and then performs some I/O on the ready descriptors before once more checking for ready file descriptors.

我不明白这个“阻塞”部分是什么意思。我认为我们使用阻塞 I/O 还是非阻塞 I/O 是无关紧要的。 (作者在本章前面也说过，无论是电平触发还是边缘触发通知，通常都会使用非阻塞I/O)

Answer 1

那么，IO 嗯？好吧，IO 是“处理事物”，因此我们可以使用人类的比喻。想象一下，您是系统上的一个进程，正在为您的老板完成工作。

然后阻塞 IO 就像去看牙医或与客户面对面会面一样。在这两种情况下，当你去参加那个事件时，你离开了你的办公 table ，所以在你回到你的办公 table 之前完全无法做任何其他事情。很有可能，您会在等候室浪费一些时间或在 session 中闲聊/等待人们出现。

阻塞 IO 就像这样 - 阻塞 IO“牺牲”(我这样说是因为你失去了线程，有效地)线程到有问题的任务。当它被阻止时，您不能将它用于任何其他目的 - 它正在等待 IO 发生。

相比之下，非阻塞 IO 就像打电话一样。当您在打电话时，您可以在 Stack Overflow 上写答案的同时参与该 IO!此类 IO 被称为异步 - 因为您接受 IO 请求并开始处理它，但可以在其他请求完成时处理它们。

现在，我最喜欢的此类资源是 c10k problem页面在这里。我会说你是对的——99% 的时间你会使用非阻塞 IO(事实上，你的操作系统一直在为你执行非阻塞 IO)，主要是因为每个线程都使用一个完整的线程传入 IO 任务的效率低得令人难以置信，即使在线程和进程是同一事物(任务)并且相当轻量级的 Linux 中也是如此。

边缘触发和水平触发通知类型之间的区别可能更适用于非阻塞连接，因为无论如何它与阻塞情况无关。据我了解，边缘触发的通知仅在您上次请求状态更新时有新数据时才将描述符标记为就绪，而水平触发则标记描述符准备好在有可用数据时进行处理。这意味着边缘触发接口(interface)是 considered a bit more tricky ，因为你必须 handle the incoming data when you see it因为您不会再收到通知。从理论上讲，这应该更有效(通知更少)。

因此，tl;dr - 边缘与级别就绪性与阻塞与非阻塞设计的考虑因素略有不同，即，有多种方法可以执行非阻塞 IO，而只有一种方法可以执行阻塞 IO。