在库代码中是否有使用信号和信号处理程序的约定/设计模式？因为信号是针对整个过程的，而不是针对特定线程或库的，所以我认为可能存在一些问题。
假设我正在编写一个共享库，该库将由其他应用程序使用，并且我想使用警报，设置函数和陷阱SIGALRM信号在特定时间进行一些处理。
我看到一些问题：
1）如果应用程序代码（我无法控制）也使用SIGALRM并且我为其安装了自己的信号处理程序，则这可能会覆盖应用程序的信号处理程序，从而禁用其功能。当然，我可以确保从我自己的信号处理程序中调用先前的信号处理程序（由signal（）函数检索），但是当应用程序代码可以覆盖我的信号处理程序并因此禁用我的库中的功能时，仍然存在一个反向问题。
2）甚至比这更糟的是，应用程序开发人员可能会链接到另一个也使用SIGALRM的供应商提供的共享库，因此，我和应用程序开发人员也不会对其进行任何控制。
3）调用alarm（）或setitimer（）将覆盖该进程使用的先前计时器，因此应用程序可以覆盖我在库中设置的计时器，反之亦然。
我对此还是一个新手，所以我想知道是否已经有一些约定可以解决这个问题？ （例如，如果每个代码都非常好，它会从自己的信号处理程序中调用先前的信号处理程序，并构造警报代码以尊重先前的计时器，然后再用自己的计时器覆盖它们）
还是应该避免在库中一起使用信号处理程序和alarm（）？
最佳答案
还是应该避免在库中一起使用信号处理程序和alarm（）？
是。由于您已经确定的原因，除非您控制应用程序中的所有代码，否则您什么都不能依赖信号处理。
您可以证明您的库要求应用程序不要使用SIGALRM，也不能调用alarm，但是应用程序开发人员无论如何都不能对此进行任何控制，因此最大的利益是避免将此类限制放在首位。地点。
如果您的库可以在没有SIGALRM的情况下工作（也许功能有所减少），则还可以将此功能设置为可选，可能由某些环境变量控制。然后，如果发现有一些代码会干扰您的信号处理，则可以告诉最终用户设置环境变量以禁用库的该部分（无需重新构建并提供新版本） ）。
附言您的问题和此答案适用于任何库，无论是共享库还是存档库。