我在线程进程环境中长时间运行boost::regex_match(...)调用时遇到问题。但它可能是另一个具有相同问题的lib（API调用）。
是否有通用的方法为此设置监视程序？
对于非线程进程alarm()可用于检测超时。
但是，信号与线程不能很好地协同工作。我可以避免在线程中直接使用alarm()并委托计时器mgt。到一个专用的单独线程，让那个使用pthread_kill(...)来解决正确的线程（这只是一个想法 - 我还没有验证那部分）。
但是，这也只会中断并检测到这种情况，但无法正常停止 boost::regex_match(...)。
我使用sigsetjmp()使用siglongjmp()和boost::regex_match(..)使用boost::regex_match(...) because进行线程。
但它会导致longjmp() siglongjmp（）中的内存泄漏绕过析构函数。
如何优雅地停止第三方API调用 - 假设它已实现异常安全？
或者它是否必须得到第三方API中积极实施的某些“可停止”功能的支持？ （是否有一些用于升级库？）
也许有些奇怪的想法，但是：
代码可以实现为“线程安全”和/或“异常安全”。
是否可以选择定义“longjmp-safe”？这可以通过将附加令牌传递给lib来完成，以便将所有资源分配与该令牌相关联。在<head>之后，客户端SW可以单独请求API释放这些资源。
更简单可能只是一些中心的init（）/ release（）或register（）/ unregister（）API调用，API可以通过它来清理自己。
答案 0 :(得分：0)
如果您必须：
你应该只考虑任务而不是线程。
使用线程听起来像是＃34;最先进的＆＃34;但在实践中，任务通常是更好的实施方式。特别是对于控制记忆韭菜＆＃34; undefined＆＃34;执行结束，限制不必要的内存过量并控制堆栈溢出等。
在你提到的情况下，我倾向于将其作为任务来实现。 IPC在所有已知平台上运行良好，但不可移植。如果可移植性没有问题，那么更改为基于任务的解决方案并不是什么大问题。
挂起任务可以通过os调用终止，并且所有锁，内存和其他资源（如ipc / shared memory / pipes等）将自动删除。因此，这更适合您的问题，并且它不依赖于您的外部和可能不可更改的第三方组件。