c - Linux select() vs ppoll() vs pselect()

Question

在我的应用程序中，有一个 io 线程，专用于

1. 在自定义协议(protocol)中包装从应用程序接收的数据
2. 通过tcp/ip发送数据+自定义协议(protocol)包
3. 通过tcp/ip接收数据+自定义协议(protocol)包
4. 解包自定义协议(protocol)并将数据交给应用程序。

应用程序通过不同的线程处理数据。此外，要求规定未确认的窗口大小应为 1，即在任何时候都应该只有一个待处理的未确认消息。这意味着如果 io-thread 已经通过套接字发送了一条消息，它将不会再发送任何消息，直到它听到来自接收方的确认。应用程序的处理线程通过管道与 io-thread 通信。如果有人从 linux CLI 键入 ctrl+C，应用程序需要正常关闭。因此，鉴于这些要求，我有以下选择

1. 在套接字和管道描述符上使用 PPoll()
2. 使用 Select()
3. 使用 PSelect()

我有以下问题

1. select() 和 poll() 之间的决定。我的应用程序只处理少于 50 个文件描述符。可以假设我选择 select 还是 poll 没有区别吗？

   1. select() 和 pselect() 之间的决定。我阅读了 linux 文档，它说明了信号和 select() 之间的竞争条件。我没有信号方面的经验，所以有人可以更清楚地解释竞争条件和 select() 吗？是否与有人在 CLI 上按 ctrl+C 而应用程序没有停止有关？

   2. pselect 和 ppoll() 之间的决定？关于一个与另一个的任何想法

Answer 1

我建议先比较 select() 与 poll()。 Linux 还同时提供了pselect() 和ppoll()；以及 pselect() 和 ppoll() 的额外 const sigset_t * 参数(对比 select() 和 poll()) 对每个“p-variant”具有相同的效果。如果你不使用信号，你就没有竞争来防止，所以基本问题实际上是关于编程的效率和易用性。

同时这里已经有一个 stackoverflow.com 的答案:what are the differences between poll and select .

至于比赛:一旦你开始使用信号(无论出于何种原因)，你将了解到，一般来说，信号处理程序应该只设置一个 volatile sig_atomic_t 类型的变量来指示信号已被检测到。根本原因是许多库调用不是 re-entrant ，并且可以在您“处于”这样的例程中时发出信号。例如，简单地将消息打印到流式数据结构，例如 stdout (C) 或 cout (C++) 可能会导致重入问题。

假设您有使用 volatile sig_atomic_t flag 变量的代码，可能是为了捕获 SIGINT，就像这样(另请参见 http://pubs.opengroup.org/onlinepubs/007904975/functions/sigaction.html ):

volatile sig_atomic_t got_interrupted = 0;
void caught_signal(int unused) {
    got_interrupted = 1;
}
...
    struct sigaction sa;
    sa.sa_handler = caught_signal;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;
    if (sigaction(SIGINT, &sa, NULL) == -1) ... handle error ...
    ...

现在，在您的代码主体中，您可能希望“运行直到被中断”:

    while (!got_interrupted) {
         ... do some work ...
    }

这很好，直到您开始需要进行等待某些输入/输出的调用，例如 select 或 poll。 “等待”操作需要等待该 I/O——但它也需要等待 SIGINT 中断。如果你只是写:

    while (!got_interrupted) {
        ... do some work ...
        result = select(...); /* or result = poll(...) */
    }

那么中断有可能就在您调用select() 或poll() 之前发生，而不是之后发生。在这种情况下，您确实被打断了——并且变量 got_interrupted 被设置了——但在那之后，您开始等待。您应该在开始等待之前检查 got_interrupted 变量，而不是之后。

你可以试试写:

    while (!got_interrupted) {
        ... do some work ...
        if (!got_interrupted)
            result = select(...); /* or result = poll(...) */
    }

这缩小了“竞赛窗口”，因为现在您将检测到在您处于“做一些工作”代码时发生的中断；但是仍然存在竞争，因为中断可能发生在您测试变量之后，但就在 select-or-poll 之前。

解决方案是使用 sigprocmask 的信号阻塞属性(或者，在 POSIX 线程代码中，pthread_sigmask)使“测试，然后等待”序列成为“原子的” >):

sigset_t mask, omask;
...
while (!got_interrupted) {
    ... do some work ...
    /* begin critical section, test got_interrupted atomically */
    sigemptyset(&mask);
    sigaddset(&mask, SIGINT);
    if (sigprocmask(SIG_BLOCK, &mask, &omask))
        ... handle error ...
    if (got_interrupted) {
        sigprocmask(SIG_SETMASK, &omask, NULL); /* restore old signal mask */
        break;
    }
    result = pselect(..., &omask); /* or ppoll() etc */
    sigprocmask(SIG_SETMASK, &omask, NULL);
    /* end critical section */
}

(上面的代码实际上并不是那么好，它的结构是为了说明而不是效率——稍微不同地进行信号掩码操作，并以不同方式放置“被中断”测试会更有效)。

不过，在您真正开始需要捕获 SIGINT 之前，您只需要比较 select() 和 poll()(如果您开始需要大量的描述符，一些基于事件的东西比如 epoll() 比任何一个都更有效。