将epoll与设备（/dev/event/…）一起使用是否有效？

Question

我正在开发一个单线程进程小程序，它可以创建一个代理虚拟设备（更确切地说是一个虚拟Xbox 360 pad）；我确实使用uinput接口创建了它，我正确地设置了它，它工作得很好。

为了将命令馈送到此虚拟设备，我从另一个真实接口（在本例中为PS3 pad）读取事件，并使用以下标志打开真实设备文件：

fd = open("/dev/input/event22", O_RDONLY); // open the PS3 pad

主循环类似于（减去错误检查）：

while(run) {
    input_event ev = {0};
    read(fd, &ev, sizeof(struct input_event));
    // convert from PS3 --> Xbox 360
    convert(ev);
    // write to the new virtual pad
    write(fd_virtual, &ev, sizeof(struct input_event));
}

正如您所想象的，读取（fd，

出于这些原因，我正在考虑将读取（fd…调用封装在一个epoll循环中，这样我也可以有一个超时。

问题是，这样做是否有效？通过使用epoll\u wait，我是否给当前循环引入了额外的延迟，从而延迟了虚拟pad的响应？

Answer 1

通过使用epoll_wait，我是否向当前循环引入了额外的延迟，从而延迟了虚拟垫的响应能力？

是的，你当然知道。

这样做是否有效？

我肯定是的，但这在很大程度上取决于你对“效率”的定义。

我们在这里讨论的是一个人工输入设备。在处理HID时，我们最关心的是延迟，它不应该滞后，按键时的反应应该是即时的。什么是人类的“瞬间”？这里有一个很好的讨论，但我最喜欢的一个论点是，在高水平的田径比赛中，你在接到信号后不到100毫秒就会被取消比赛资格。

但是100毫秒是对输入信号进行整个处理的时间预算，从按键到游戏中的一些可感知的变化。维基百科关于输入延迟的页面有一些关于该预算通常如何使用的数字。

无论如何，我认为1毫秒是绝对安全的开销，您可以使用代理添加，没有人会注意到，假设这是我们最大延迟的目标（如“高效”的定义）。

所以，让我们假设您对当前代码的响应时间感到满意。当您添加eball（）调用时会发生什么变化？基本上，您正在为另一个系统调用添加一些时间，因为现在不是一个系统调用来获取您正在生成的值，而是两个。因此，它可能比您的原始代码慢两倍（让我们暂时忘记不同系统调用的流转时长差异）。但它真的那么糟糕吗？

为了回答这个问题，我们需要对系统调用开销进行一些估计。如果我们懒得自己来衡量，我们可以使用20年前的一些数字，一些来自关心系统调用的人的数字，一些来自微核人员（他们总是关心）的IPC数字，一些来自StackOverflow的随机数字，或者只是问问Rich，然后在微秒级左右结算，作为一个安全的假设。

因此，问题归根结底是，在毫秒（如1000µs）的时间预算内，是否可以注意到添加一些（甚至可以说10）微秒。我想不是。

只有一个可能的小问题，当您要从“只是添加电子投票（）”到

循环遍历循环并检查其他事件/执行其他代码。

对于这些循环和检查，您需要小心地保持在您的时间预算范围内。但话说回来，1毫秒对您来说可能已经足够了。