在我的应用程序中,有一个 io 线程,专用于
- 在自定义协议(protocol)中包装从应用程序接收的数据
- 通过tcp/ip发送数据+自定义协议(protocol)包
- 通过tcp/ip接收数据+自定义协议(protocol)包
- 解包自定义协议(protocol)并将数据交给应用程序。
应用程序通过不同的线程处理数据。此外,要求规定未确认的窗口大小应为 1,即在任何时候都应该只有一个待处理的未确认消息。这意味着如果 io-thread 已经通过套接字发送了一条消息,它将不会再发送任何消息,直到它听到来自接收方的确认。 应用程序的处理线程通过管道与 io-thread 通信。如果有人从 linux CLI 键入 ctrl+C,应用程序需要正常关闭。 因此,鉴于这些要求,我有以下选择
- 在套接字和管道描述符上使用 PPoll()
- 使用 Select()
- 使用 PSelect()
我有以下问题
select() 和 poll() 之间的决定。我的应用程序只处理少于 50 个文件描述符。可以假设我选择 select 还是 poll 没有区别吗?
select() 和 pselect() 之间的决定。我阅读了 linux 文档,它说明了信号和 select() 之间的竞争条件。我没有信号方面的经验,所以有人可以更清楚地解释竞争条件和 select() 吗?是否与有人在 CLI 上按 ctrl+C 而应用程序没有停止有关?
pselect 和 ppoll() 之间的决定?关于一个与另一个的任何想法
最佳答案
我建议先比较 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()
比任何一个都更有效。
关于c - Linux select() vs ppoll() vs pselect(),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9774986/