c setitimer 在其调用范围之外时不发送信号

Question

我有以下情况

void foo() {
   printf("hi\n");  
   while(1);

}


int main(void)
{
  struct sigaction temp;
  temp.sa_handler = &foo;
  sigfillset(&temp.sa_mask);
  sigdelset(&temp.sa_mask, SIGVTALRM);
  sigdelset(&temp.sa_mask, SIGINT );
  sigaction(SIGVTALRM, &temp, NULL);
  struct itimerval tv;
  tv.it_value.tv_sec = 2;  /* first time interval, seconds part */
  tv.it_value.tv_usec = 0; /* first time interval, microseconds part */
  tv.it_interval.tv_sec = 2;  /* following time intervals, seconds part */
  tv.it_interval.tv_usec = 0; /* following time intervals, microseconds part */

  if (setitimer(ITIMER_VIRTUAL, &tv, NULL)){
    perror(NULL);
  }
  while(1);
  return 0;
}

我想要的是每 2 秒 foo 被调用一次(foo 实际上做了一些除了 while(1) 之外的其他事情，只是假设 foo 运行需要超过 2 秒)，2 秒后 foo 确实被调用但是没有在 foo 返回之前进行其他调用。我尝试使用信号掩码(因此使用 sigfillset)，但在简单地调用 signal(SIGVTALRM, foo) 时也没有对结果进行任何更改。我还尝试在 main 外部声明 itimerval 和 sigactions 变量，但它并没有完全影响任何东西。

我正在尝试做的事情是否可行？

谢谢!

Answer 1

reference: <http://www.gnu.org/software/libc/manual/html_node/Signals-in-Handler.html>

 24.4.4 Signals Arriving While a Handler Runs

如果在您的信号处理函数运行时另一个信号到达会怎样？

当调用特定信号的处理程序时，该信号会自动阻塞，直到处理程序返回。这意味着如果两个相同类型的信号同时到达，第二个信号将被保留，直到第一个信号被处理。 (如果您想允许更多此类信号到达，处理程序可以使用 sigprocmask 显式解除对信号的阻塞；请参阅 Process Signal Mask。)

但是，您的处理程序仍可能被另一种信号的传递中断。为避免这种情况，您可以使用传递给 sigaction 的操作结构的 sa_mask 成员来明确指定在信号处理程序运行时应阻止哪些信号。这些信号是调用处理程序的信号以及通常被进程阻塞的任何其他信号的补充。请参阅处理程序的阻塞。

当处理程序返回时，阻塞信号集将恢复为处理程序运行前的值。因此，在处理程序内部使用 sigprocmask 只会影响在处理程序本身执行期间哪些信号可以到达，而不会影响处理程序返回后哪些信号可以到达。

可移植性注意事项:如果您希望您的程序在 System V Unix 上正常运行，请始终使用 sigaction 为您希望异步接收的信号建立处理程序。在此系统上，处理其处理程序已通过信号建立的信号会自动将信号的操作设置回 SIG_DFL，并且处理程序必须在每次运行时重新建立自身。这种做法虽然不方便，但在信号不能连续到达时确实有效。但是，如果另一个信号可以立即到达，它可能会在处理程序重新建立自身之前到达。然后第二个信号将接收默认处理，这可能会终止进程。

reference:<http://www.gnu.org/software/libc/manual/html_node/Process-Signal-Mask.html#Process-Signal-Mask>

24.7.3 过程信号掩码

当前被阻塞的信号集合称为信号掩码。每个进程都有自己的信号掩码。当您创建一个新进程时(请参阅创建进程)，它会继承其父进程的掩码。您可以通过修改信号掩码来完全灵活地阻止或取消阻止信号。

sigprocmask 函数的原型(prototype)在 signal.h 中。

注意在多线程进程中一定不要使用sigprocmask，因为每个线程都有自己的信号掩码，没有单一进程的信号掩码。根据 POSIX，sigprocmask 在多线程进程中的行为是“未指定的”。相反，请使用 pthread_sigmask。

Function: int sigprocmask (int how, const sigset_t *restrict set, sigset_t *restrict oldset)

Preliminary: | MT-Unsafe race:sigprocmask/bsd(SIG_UNBLOCK) | AS-Unsafe lock/hurd | AC-Unsafe lock/hurd | See POSIX Safety Concepts.

The sigprocmask function is used to examine or change the calling process’s signal mask. The how argument determines how the signal mask is changed, and must be one of the following values:

SIG_BLOCK

Block the signals in set—add them to the existing mask. In other words, the new mask is the union of the existing mask and set.

SIG_UNBLOCK

Unblock the signals in set—remove them from the existing mask.

SIG_SETMASK

Use set for the mask; ignore the previous value of the mask.

The last argument, oldset, is used to return information about the old process signal mask. If you just want to change the mask without looking at it, pass a null pointer as the oldset argument. Similarly, if you want to know what’s in the mask without changing it, pass a null pointer for set (in this case the how argument is not significant). The oldset argument is often used to remember the previous signal mask in order to restore it later. (Since the signal mask is inherited over fork and exec calls, you can’t predict what its contents are when your program starts running.)

If invoking sigprocmask causes any pending signals to be unblocked, at least one of those signals is delivered to the process before sigprocmask returns. The order in which pending signals are delivered is not specified, but you can control the order explicitly by making multiple sigprocmask calls to unblock various signals one at a time.

The sigprocmask function returns 0 if successful, and -1 to indicate an error. The following errno error conditions are defined for this function:

EINVAL

The how argument is invalid.

You can’t block the SIGKILL and SIGSTOP signals, but if the signal set includes these, sigprocmask just ignores them instead of returning an error status.

Remember, too, that blocking program error signals such as SIGFPE leads to undesirable results for signals generated by an actual program error (as opposed to signals sent with raise or kill). This is because your program may be too broken to be able to continue executing to a point where the signal is unblocked again. See Program Error Signals.