信号和库

Question

在库代码中使用信号和信号处理程序是否有任何约定/设计模式？因为信号是指向整个过程而不是指向特定的线程或库，所以我觉得可能有一些问题。

比方说，我正在写，这将被其他应用程序使用的共享库，我想使用报警，setitimer功能和陷阱SIGALRM信号在特定的时间做一些处理。

我看到一些问题吧：

1）如果应用程序代码（我没有控制）也使用SIGALRM和我安装我自己的信号处理它，这可能会重写应用程序的信号处理程序，因此禁用它的功能。当然，我可以确保从我自己的信号处理程序调用先前的信号处理程序（由signal（）函数检索），但是当应用程序代码可以覆盖我的信号处理程序并因此禁用我的库中的功能时，仍然存在相反的问题。

2）即使更糟糕的，应用程序开发者可以与另一共享库从它也使用SIGALRM，因此也没有我，也不应用开发者必须在它的任何控制另一个供应商链接。

3）调用警报（）或setitimer（）将覆盖过程中使用的前一计时器，所以应用程序可能会覆盖我在图书馆设置或反之亦然定时器。

余米还挺这个新手，所以单读音不知道是否已经有一些约定来处理呢？ （例如，如果每个代码都非常好，它会从它们自己的信号处理程序中调用先前的信号处理程序，并且还会构造警报代码以便在用自己的定时器覆盖它们之前兑现先前的定时器）

或者我应该避免使用信号处理程序和警报（）在一个库中一起？

Answer 1

或者我应该避免在库中使用信号处理程序和闹钟（）？

是。出于您已经确定的原因，除非您控制应用程序中的所有代码，否则不能依赖任何信号处置。

您可能文档库中要求应用程序无法使用SIGALRM，也不叫alarm，但应用开发者可以没有任何控制权的是，无论如何，所以它在避免放置在这样的限制您的最佳利益第一个地方。

如果磁带库可以在不SIGALRM工作（也许功能有所降低），还可以使此功能选配，也许一些环境变量控制。然后，如果发现有一些代码干扰了信号处理，则可以告诉最终用户设置环境变量以禁用该库的那部分内容（这不仅需要重建并提供它的新版本）。

P.S.您的问题和此答案适用于任何库，无论是共享还是归档。