杀死导致 SIGSEGV 的线程
一些信息：我必须编写一个控制某些设备的程序（这是基本功能）。但我必须编写某种插件系统来启用其他自定义功能。我无法控制这些插件的源质量，所以我想我将为每个加载的插件创建一个线程，然后它将在它自己的主循环中运行。我能够捕获标准 C++ 异常，但问题是我不知道如何处理信号。最好的方法是异步取消插件的线程，让他有机会清理和释放资源，或者只是杀死他，但不知道如何找出哪个线程导致当前信号。有没有办法在不将当前执行的线程信息显式保存在某个变量中的情况下执行此操作？或者这完全是个坏主意，我应该创建单独的进程然后运行插件？
Some information: i have to write a program that controls some devices (this is basic functionality). But i have to write some kind of plugin system to enable other custom functionality. I have no way of controling those plugins source quality so i figured that i will create a thread for every loaded plugin and then it will run in it's own main loop. I am able to catch standard C++ exceptions but problem is that i have no idea how to deal with signals. Best way would be to asynchronously cancel plugin's thread to give him chance to clean up and free resource or just kill him but do not know how to find out which thread causes current signal. Is there a way to do this without explicity saving currently excuted thread info in some variable? Or this is totaly bad idea and i should create separate process and then run the plugin?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，这完全是个坏主意。线程是一种协作的、共享几乎所有内容的编程模型，不提供任何隔离。对于这项工作来说，这只是一个错误的工具。
Yes, this is totally a bad idea. Threads are a cooperative, share almost everything, programming model that doesn't provide any isolation. It's just the wrong tool for this job.
我会使用传统进程来获得完全隔离并使用IPC机制进行通信。
I would use traditional process to get total isolation and use IPC mechanism for communication.