Linux 中的 C++ : In what forked-task context should a timer callback execute?

Question

我在 Linux 中用 C/C++ 实现了自己的定时器/回调类，其中需要定时器触发 ONE_SHOT 或 PERIODICally 的进程实例化定时器，并实例化回调对象并将回调与先前创建的定时器对象相关联。 Callback 类实现了一个 triggered() 方法，当定时器在指定的超时时间触发时，triggered() 方法就会被执行。 (在功能方面没有什么新东西。)我的 Timer 类的工作方式是我维护一个 Timer 对象的最小堆，因此总是知道接下来要触发哪个计时器。有一个定时器任务 (TimerTask)，它本身作为一个单独的进程运行(使用 fork() 创建)并共享从中创建 Timer 对象和 Callback 对象的内存池。 TimerTask 有一个主要的 while (1) 循环，它不断检查 Timer 对象 minheap 的根是否有自纪元以来的时间，即自纪元以来的当前时间。如果是，则根部的计时器已“触发”。

目前，当计时器触发时，回调在 TimerTask 进程上下文中执行。我目前正在更改此行为以在其他任务上运行回调处理(通过 POSIX 消息队列向它们发送 Timer 对象已触发的信息。例如，将消息发送到 Timer 对象创建过程)，但我的问题是这背后的原理是什么？如果我希望为大量计时器提供服务，那么在 TimerTask 上下文中执行回调似乎不是一个好主意。将回调处理分派(dispatch)给其他进程似乎是个好主意。

在一个任务/进程中处理回调的一般经验法则是什么？我的意图是使用 pthread 处理接收任务中的回调，如下所示:

void threadFunctionForTimerCallback (void* arg)
{
    while (1)
    {
      if ((mq_receive (msg_fd, buffer, attr.mq_msgsize, NULL)) == -1)
    exit (-1);
      else
    printf ("Message received %s\n", buffer);
    }
}

这是一个合理的解决方案吗？但不要介意从 TimerTask 接收消息的实际方式(线程或任何其他方法，无关紧要)，任何关于为回调分配任务的问题的讨论和见解都是值得赞赏的。

Answer 1

无需忙于自旋 while(1) 来实现计时器。实现定时器的一种传统且稳健的方法是使用 minheap 来组织到期时间，然后将时间传递到下一个定时器到期，作为 select() 或 epoll 的超时参数()。使用 select() 调用线程可以同时监视文件描述符准备情况、信号和计时器。

最近的内核支持 timerfd将计时器到期事件作为文件描述符准备好读取，再次可以使用 select()/epoll() 处理。它避免了维护最小堆的需要，但是，每次添加/修改/删除计时器都需要系统调用。

在另一个进程中拥有定时器代码需要进程使用进程间通信机制，从而引入更多的复杂性，因此它实际上会降低系统的健壮性，尤其是当进程通过共享内存通信并可能破坏它时。

无论如何，可以使用 Unix 域套接字在同一主机上的通信进程之间来回发送消息。同样，select()/epoll() 是您最好的 friend 。或者可以使用更高级别的框架来传递消息，例如 0MQ .