C++ 在无选择的非阻塞套接字上读取（）以降低延迟

我有一个从非阻塞套接字读取的独立线程，我可以使用尽可能多的CPU，因为低延迟是项目最重要的方面。简单地循环read（）调用会比首先使用select（）查找可读的套接字更快吗

伪代码：

while (!finished) {

    int rc = read(socket, buf);
    if (rc > 0) {
        // process buf
    } else if (rc == 0) {
        // eof, reconnect to server
    } else if (errno == EGAIN) {
        // nothing to do, continue
    } else if (errno == ECONNREFUSED) {
        // connection refused, attempt connect again
    } else {
        // error not yet supported
    }
}

---

不，它不会更快，因为您不知道数据何时到达。所以，要么你睡得太久，这不是更快，要么你睡得太短，在这种情况下，你必须重新睡一遍，这不是更快，要么你会运气好，睡得正是时候，这不是更快，需要运气，要么你根本不睡，这意味着你必须烧掉CPU，直到数据到达，这也不会更快。

如果你要这么做。。。你为什么不直接读一读呢？同意。将

read（）

放在一个单独的线程中意味着它可以在不暂停应用程序其余部分的情况下进行阻塞。只有当套接字上的数据不可用时，线程需要执行其他操作时，才需要非阻塞I/O。思考过程的一部分是，与等待读取的阻塞套接字或使用select的非阻塞套接字相比，旋转线程不太可能进行上下文切换。旋转线程通常不利于延迟；它可能会阻止其他线程，并减慢系统的其余部分。。。如果您在动态优先级调度程序（例如Linux的默认调度程序）下运行，则旋转线程的优先级将动态降低（以便其他线程首先获得CPU的DIBB），这实际上会增加线程的延迟。所以我同意Barmar的观点，最好使用阻塞读取（或者如果只注册了几个套接字，甚至select（）也可以）。请注意，如果您真的想要低延迟，更好的方法是提高线程或进程的优先级（例如，在Linux下，使用sched_setscheduler（）和sched_RR或sched_FIFO参数），或者甚至切换到像Xenomai或VxWorks这样的硬实时操作系统，为您提供延迟保证。他从来没有说过任何关于睡眠的事情。@Barmar，标题是“根本不会睡觉”。我在这里所做的是列举所有的可能性（除了使用阻塞模式，这是他应该做的）。这个线程有一个专用的核心，所以烧毁cpu对我来说似乎不是一个问题。在这和不执行选择或阻塞读取之间，我希望能够防止线程被关闭。它仍然不会以任何你可以实际测量的方式更快。网络带宽的限制比调度效果更为显著。